* Re: [PATCH v3 5/6] grep: enable recurse-submodules to work on <tree> objects
From: Jonathan Tan @ 2016-11-14 18:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, sbeller, Brandon Williams
In-Reply-To: <xmqqk2c6x79c.fsf@gitster.mtv.corp.google.com>
On 11/14/2016 10:10 AM, Junio C Hamano wrote:
> Brandon Williams <bmwill@google.com> writes:
>
>> Teach grep to recursively search in submodules when provided with a
>> <tree> object. This allows grep to search a submodule based on the state
>> of the submodule that is present in a commit of the super project.
>>
>> When grep is provided with a <tree> object, the name of the object is
>> prefixed to all output. In order to provide uniformity of output
>> between the parent and child processes the option `--parent-basename`
>> has been added so that the child can preface all of it's output with the
>> name of the parent's object instead of the name of the commit SHA1 of
>> the submodule. This changes output from the command
>> `git grep -e. -l --recurse-submodules HEAD` from:
>> HEAD:file
>> <commit sha1 of submodule>:sub/file
>>
>> to:
>> HEAD:file
>> HEAD:sub/file
>>
>> Signed-off-by: Brandon Williams <bmwill@google.com>
>> ---
>
> Unrelated tangent, but this makes readers wonder what the updated
> trailer code would do to the last paragraph ;-). Does it behave
> sensibly (with some sane definition of sensibleness)?
>
> I am guessing that it would, because neither To: or HEAD: is what we
> normally recognize as a known trailer block element.
Yes, it behaves sensibly :-) because "Signed-off-by:" is preceded by a
blank line, so the trailer block consists only of that line.
Having said that, it is probably better to indent those examples in the
commit message (by at least one space or one tab) - then they will never
be confused with trailers (once my patch set is in).
^ permalink raw reply
* [GIT PULL] ARM: at91: drivers for 4.10
From: Alexandre Belloni @ 2016-11-14 18:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof
A few fixes for the memory drivers and the support for the Secure SRAM
found on sama5d2.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.10-drivers
for you to fetch changes up to 2ae2e28852f21ec9efc527c1f3ecc5f7c7e27e42:
misc: sram: add Atmel securam support (2016-11-07 23:43:28 +0100)
----------------------------------------------------------------
Drivers for 4.10:
- few fixes for the memory drivers
- minimal security module driver
- support for the Secure SRAM
----------------------------------------------------------------
Alexandre Belloni (4):
Documentation: dt: atmel-at91: Document secumod bindings
ARM: at91: add secumod register definitions
misc: sram: document new compatible
misc: sram: add Atmel securam support
Wei Yongjun (2):
memory: atmel-ebi: fix return value check in at91_ebi_dev_disable()
memory: atmel-sdramc: use builtin_platform_driver to simplify the code
.../devicetree/bindings/arm/atmel-at91.txt | 16 +++++++++
Documentation/devicetree/bindings/sram/sram.txt | 2 +-
drivers/memory/atmel-ebi.c | 2 +-
drivers/memory/atmel-sdramc.c | 6 +---
drivers/misc/sram.c | 42 ++++++++++++++++++----
include/soc/at91/atmel-secumod.h | 19 ++++++++++
6 files changed, 73 insertions(+), 14 deletions(-)
create mode 100644 include/soc/at91/atmel-secumod.h
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/287d05f1/attachment-0001.sig>
^ permalink raw reply
* Re: [PATCH 2/2] Add basic support for DW CSI-2 Host IPK
From: kbuild test robot @ 2016-11-14 18:44 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw, arnd-r2nGTMty4D4,
sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
simon.horman-wFxRvT7yatFl57MIdRCFDg,
songjun.wu-UWL1GkI3JZL3oGB3hsPCZA, bparrot-l0cyMroinI0,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w,
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <c1699c43562aaae69ab851ff3955086131119c51.1479132355.git.roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5550 bytes --]
Hi Ramiro,
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.9-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ramiro-Oliveira/Add-support-for-the-DW-IP-Prototyping-Kits-for-MIPI-CSI-2-Host/20161115-014759
base: git://linuxtv.org/media_tree.git master
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/media/platform/dwc/dw_mipi_csi.h:12,
from drivers/media/platform/dwc/dw_mipi_csi.c:14:
drivers/media/platform/dwc/dw_mipi_csi.c: In function 'dw_mipi_csi_irq1':
>> drivers/media/platform/dwc/dw_mipi_csi.c:437:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
>> drivers/media/platform/dwc/dw_mipi_csi.c:436:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT PHY FATAL: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:443:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:442:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT PKT FATAL: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:449:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:448:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT FRAME FATAL: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:455:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:454:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT PHY: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:461:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:460:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT PKT: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:467:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:466:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT LINE: %08X\n",
^~~~~~~~~~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:473:9: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
(uint32_t) dev->base_address, ind_status);
^
include/linux/printk.h:398:17: note: in definition of macro 'printk_ratelimited'
printk(fmt, ##__VA_ARGS__); \
^~~~~~~~~~~
drivers/media/platform/dwc/dw_mipi_csi.c:472:3: note: in expansion of macro 'pr_info_ratelimited'
pr_info_ratelimited("%08X CSI INT IPI: %08X\n",
^~~~~~~~~~~~~~~~~~~
vim +437 drivers/media/platform/dwc/dw_mipi_csi.c
430
431 int_status = dw_mipi_csi_read(dev, R_CSI2_INTERRUPT);
432 spin_lock_irqsave(&dev->slock, flags);
433
434 if (int_status & CSI2_INT_PHY_FATAL) {
435 ind_status = dw_mipi_csi_read(dev, R_CSI2_INT_PHY_FATAL);
> 436 pr_info_ratelimited("%08X CSI INT PHY FATAL: %08X\n",
> 437 (uint32_t) dev->base_address, ind_status);
438 }
439
440 if (int_status & CSI2_INT_PKT_FATAL) {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 45123 bytes --]
^ permalink raw reply
* Re: [PATCH tip/core/rcu 5/7] torture: Trace long read-side delays
From: Paul E. McKenney @ 2016-11-14 18:44 UTC (permalink / raw)
To: Josh Triplett
Cc: linux-kernel, mingo, jiangshanlai, dipankar, akpm,
mathieu.desnoyers, tglx, peterz, rostedt, dhowells, edumazet,
dvhart, fweisbec, oleg, bobby.prani
In-Reply-To: <20161114172110.yybjdk6p6754nlih@jtriplet-mobl2.jf.intel.com>
On Mon, Nov 14, 2016 at 09:21:10AM -0800, Josh Triplett wrote:
> On Mon, Nov 14, 2016 at 08:57:11AM -0800, Paul E. McKenney wrote:
> > Although rcutorture will occasionally do a 50-millisecond grace-period
> > delay, these delays are quite rare. And rightly so, because otherwise
> > the read rate would be quite low. Thie means that it can be important
> > to identify whether or not a given run contained a long-delay read.
> > This commit therefore inserts a trace_rcu_torture_read() event to flag
> > runs containing long delays.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> A couple of apparent typos below. With those fixed:
> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
>
> > include/trace/events/rcu.h | 5 ++++-
> > kernel/rcu/rcutorture.c | 11 ++++++++++-
> > 2 files changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h
> > index d3e756539d44..b31e05bc8e26 100644
> > --- a/include/trace/events/rcu.h
> > +++ b/include/trace/events/rcu.h
> > @@ -698,7 +698,10 @@ TRACE_EVENT(rcu_batch_end,
> > /*
> > * Tracepoint for rcutorture readers. The first argument is the name
> > * of the RCU flavor from rcutorture's viewpoint and the second argument
> > - * is the callback address.
> > + * is the callback address. The third callback is the start time in
> > + * seconds, and the last two arguments are the grace period numbers
> > + * and the beginning and end of the read, respectively. Note that the
> > + * callback address can be NULL.
>
> s/third callback/third argument/?
Good catch, fixed!
> Also, s/and the beginning/of the beginning/?
Let's see... "the last two arguments are the grace period numbers and
the beginning and end of the read, respectively." -ENONSENSE for sure.
I believe that the "and" needs to become "at" as follows:
"the last two arguments are the grace period numbers at the beginning
and end of the read, respectively."
Does that help?
Thanx, Paul
> > TRACE_EVENT(rcu_torture_read,
> >
> > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> > index bf08fee53dc7..87c51225ceec 100644
> > --- a/kernel/rcu/rcutorture.c
> > +++ b/kernel/rcu/rcutorture.c
> > @@ -289,15 +289,24 @@ static int rcu_torture_read_lock(void) __acquires(RCU)
> >
> > static void rcu_read_delay(struct torture_random_state *rrsp)
> > {
> > + unsigned long started;
> > + unsigned long completed;
> > const unsigned long shortdelay_us = 200;
> > const unsigned long longdelay_ms = 50;
> > + unsigned long long ts;
> >
> > /* We want a short delay sometimes to make a reader delay the grace
> > * period, and we want a long delay occasionally to trigger
> > * force_quiescent_state. */
> >
> > - if (!(torture_random(rrsp) % (nrealreaders * 2000 * longdelay_ms)))
> > + if (!(torture_random(rrsp) % (nrealreaders * 2000 * longdelay_ms))) {
> > + started = cur_ops->completed();
> > + ts = rcu_trace_clock_local();
> > mdelay(longdelay_ms);
> > + completed = cur_ops->completed();
> > + do_trace_rcu_torture_read(cur_ops->name, NULL, ts,
> > + started, completed);
> > + }
> > if (!(torture_random(rrsp) % (nrealreaders * 2 * shortdelay_us)))
> > udelay(shortdelay_us);
> > #ifdef CONFIG_PREEMPT
> > --
> > 2.5.2
> >
>
^ permalink raw reply
* Re: [PATCH v2 2/2] of: changesets: Introduce changeset helper methods
From: Frank Rowand @ 2016-11-14 18:44 UTC (permalink / raw)
To: Hans de Goede, Rob Herring, Pantelis Antoniou
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b2cef3fb-cbb4-f34b-cb9a-84578bb67751-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 11/14/16 03:04, Hans de Goede wrote:
> Hi,
>
> On 14-11-16 08:34, Frank Rowand wrote:
>> Hi Hans, Pantelis,
>>
>> On 11/12/16 18:15, Frank Rowand wrote:
>>> On 11/04/16 07:42, Hans de Goede wrote:
>>>> From: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>>>
>>>> Changesets are very powerful, but the lack of a helper API
>>>> makes using them cumbersome. Introduce a simple copy based
>>>> API that makes things considerably easier.
>>>>
>>>> To wit, adding a property using the raw API.
>>>>
>>>> struct property *prop;
>>>> prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
>>>> prop->name = kstrdup("compatible");
>>>> prop->value = kstrdup("foo,bar");
>>>> prop->length = strlen(prop->value) + 1;
>>>> of_changeset_add_property(ocs, np, prop);
>>>>
>>>> while using the helper API
>>>>
>>>> of_changeset_add_property_string(ocs, np, "compatible",
>>>> "foo,bar");
>>>>
>>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>> Changes in v2 (hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>>>> -Address review comments from:
>>>> https://www.spinics.net/lists/kernel/msg2252845.html
>>>
>>> That points to the May 9 version 1 patches from Pantelis (as expected),
>>> but containing 4, not 2, patches. Patch 1/4 was applied. Patch 4/4
>>> seems to have disappeared?
>>>
>>> Pantelis then sent a version 2 set of the patches on May 16.
>>>
>>> Your version is a modification of the May 9 patches (as would be expected
>>> of a version 2). It is confusing to have two different version 2 patch
>>> sets. I don't have any brilliant ideas on how this patch set could have
>>> been named differently to avoid that confusion.
>>>
>>> The point of this little side-track is simply to note the existence of two
>>> different version 2 series so I won't be confused when I revisit this
>>> thread in the future.
>>>
>>>> -Simplify (and fix) __of_changeset_add_update_property_copy OOM handling
>>>> -Remove (by manual inlining) these 2 static helpers:
>>>> __of_changeset_add_update_property_u32
>>>> __of_changeset_add_update_property_bool
>>>> -Remove the following exported helper method:
>>>> of_changeset_node_move_to
>>>
>>> Not all comments were addressed.
>>>
>>> There are some other changes made that are not noted in the changelog.
>>>
>>> I am still reading through the patches. I will reply again either with
>>> a reviewed-by or specific comments when I finish.
>>
>> Replying here for the entire patchset (there was no patch 0 to reply to).
>>
>> After reading through the patches, my reply is meta instead of specific
>> comments about the code.
>>
>> There are very few users of change sets in tree. I do not see the need to
>> add these helpers until such users are likely to appear.
>>
>> I would expect change sets to be _mostly_ used internally by the device tree
>> overlay framework, not directly by drivers. If change sets are an attractive
>> technology for drivers, I want to approach that usage very carefully to avoid
>> inappropriate use, which could be very difficult to reign in after the fact.
>>
>> Even if helpers should be added, this seems to be an overly complex approach.
>> If the need for these helpers becomes apparent I can provide review comments
>> with the specifics about how it appears to be overly complex.
>>
>> Can you please provide some more insights into the needs driving the desire
>> to have change set helpers and the expected use cases of them? Please put
>> your architect's hat on when replying to this question.
>
> My use case for this is discussed in this thread:
> https://www.spinics.net/lists/arm-kernel/msg536111.html
>
> With the dt-bindings for the hardware-manager I want to add here:
> https://www.spinics.net/lists/arm-kernel/msg536109.html
>
> Note that there is a lot of discussion in this thread whether or
> not this belongs in the kernel. I strongly believe though that
> some functionality like this will be needed in the kernel for
> ARM+dt devices going forward, just like there is plenty of x86
> code which adjusts itself to specific hardware, because whether
> we like it or not hardware (revisions) will always have quirks.
Thanks! That context should have been provided with the patches.
The use case discussion is important and I am paying a lot of
attention to that discussion and many other discussions about
dynamic device trees. I don't think it makes sense to apply the
change set helper patches yet, given the unsettled state of the
various dynamic device tree discussions.
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net 2/3] bpf, mlx5: fix various refcount/prog issues in mlx5e_xdp_set
From: Saeed Mahameed @ 2016-11-14 18:27 UTC (permalink / raw)
To: Daniel Borkmann, davem
Cc: alexei.starovoitov, bblanco, tariqt, zhiyisun, ranas, netdev
In-Reply-To: <03741f7075af64e83d23add379bdab41204396b0.1479080215.git.daniel@iogearbox.net>
On 11/14/2016 02:43 AM, Daniel Borkmann wrote:
> There are multiple issues in mlx5e_xdp_set():
>
> 1) prog can be NULL, so calling unconditionally into bpf_prog_add(prog,
> priv->params.num_channels) can end badly.
not correct, if prog is null we will never get to bpf_prog_add:
reset = (!priv->xdp_prog || !prog);
[...]
if (!test_bit(MLX5E_STATE_OPENED, &priv->state) || reset)
goto unlock;
bpf_prog_add...
>
> 2) The batched bpf_prog_add() should be done at an earlier point in
> time. This makes sure that we cannot fail anymore at the time we
> want to set the program for each channel. This only means that we
> have to undo the bpf_prog_add() in case we return early due to
> reset or device not in MLX5E_STATE_OPENED yet. Note, err is 0 here.
>
It is delayed for a reason, we do delayed batched bpf_prog_add()
only when reset is not required (exchanging prog/old_prg) when both prog and old_prog are not null,
which means the only thing that could fail in this case is bpf_prog_add.
so i don't see any reason for changing the logic, checking for bpf_prog_add return value would be sufficient.
Sorry I need to go for now, I will continue reviewing this patch later. but this patch looks a little bit exaggerated.
> 3) When swapping the priv->xdp_prog, then no extra reference count must
> be taken since we got that from call path via dev_change_xdp_fd()
> already. Otherwise, we'd never be able to free the program. Also,
> bpf_prog_add() without checking the return code could fail.
>
> Fixes: 86994156c736 ("net/mlx5e: XDP fast RX drop bpf programs support")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 25 ++++++++++++++++++-----
> include/linux/bpf.h | 5 +++++
> kernel/bpf/syscall.c | 11 ++++++++++
> 3 files changed, 36 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index 2b83667..c90610a 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -3125,6 +3125,17 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
> goto unlock;
> }
>
> + if (prog) {
> + /* num_channels is invariant here, so we can take the
> + * batched reference right upfront.
> + */
> + prog = bpf_prog_add(prog, priv->params.num_channels);
> + if (IS_ERR(prog)) {
> + err = PTR_ERR(prog);
> + goto unlock;
> + }
> + }
> +
> was_opened = test_bit(MLX5E_STATE_OPENED, &priv->state);
> /* no need for full reset when exchanging programs */
> reset = (!priv->xdp_prog || !prog);
> @@ -3132,10 +3143,10 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
> if (was_opened && reset)
> mlx5e_close_locked(netdev);
>
> - /* exchange programs */
> + /* exchange programs, extra prog reference we got from caller
> + * as long as we don't fail from this point onwards.
> + */
> old_prog = xchg(&priv->xdp_prog, prog);
> - if (prog)
> - bpf_prog_add(prog, 1);
> if (old_prog)
> bpf_prog_put(old_prog);
>
> @@ -3146,12 +3157,11 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
> mlx5e_open_locked(netdev);
>
> if (!test_bit(MLX5E_STATE_OPENED, &priv->state) || reset)
> - goto unlock;
> + goto unlock_put;
>
> /* exchanging programs w/o reset, we update ref counts on behalf
> * of the channels RQs here.
> */
> - bpf_prog_add(prog, priv->params.num_channels);
> for (i = 0; i < priv->params.num_channels; i++) {
> struct mlx5e_channel *c = priv->channel[i];
>
> @@ -3173,6 +3183,11 @@ static int mlx5e_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
> unlock:
> mutex_unlock(&priv->state_lock);
> return err;
> +unlock_put:
> + /* reference on priv->xdp_prog is still held at this point */
> + if (prog)
> + bpf_prog_sub(prog, priv->params.num_channels);
> + goto unlock;
> }
>
> static bool mlx5e_xdp_attached(struct net_device *dev)
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index c201017..ca495fd 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -234,6 +234,7 @@ u64 bpf_event_output(struct bpf_map *map, u64 flags, void *meta, u64 meta_size,
> struct bpf_prog *bpf_prog_get(u32 ufd);
> struct bpf_prog *bpf_prog_get_type(u32 ufd, enum bpf_prog_type type);
> struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i);
> +void bpf_prog_sub(struct bpf_prog *prog, int i);
> struct bpf_prog *bpf_prog_inc(struct bpf_prog *prog);
> void bpf_prog_put(struct bpf_prog *prog);
>
> @@ -303,6 +304,10 @@ static inline struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i)
> return ERR_PTR(-EOPNOTSUPP);
> }
>
> +static inline void bpf_prog_sub(struct bpf_prog *prog, int i)
> +{
> +}
> +
> static inline void bpf_prog_put(struct bpf_prog *prog)
> {
> }
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 751e806..a0fca9f 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -682,6 +682,17 @@ struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i)
> }
> EXPORT_SYMBOL_GPL(bpf_prog_add);
>
> +void bpf_prog_sub(struct bpf_prog *prog, int i)
> +{
> + /* Only to be used for undoing previous bpf_prog_add() in some
> + * error path. We still know that another entity in our call
> + * path holds a reference to the program, thus atomic_sub() can
> + * be safely used in such cases!
> + */
> + WARN_ON(atomic_sub_return(i, &prog->aux->refcnt) == 0);
> +}
> +EXPORT_SYMBOL_GPL(bpf_prog_sub);
> +
> struct bpf_prog *bpf_prog_inc(struct bpf_prog *prog)
> {
> return bpf_prog_add(prog, 1);
>
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Zygo Blaxell @ 2016-11-14 18:43 UTC (permalink / raw)
To: James Pharaoh; +Cc: Mark Fasheh, linux-btrfs
In-Reply-To: <a4e42724-d84a-e4f9-a3ea-d1fec31a5629@wellbehavedsoftware.com>
[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]
On Mon, Nov 14, 2016 at 07:22:59PM +0100, James Pharaoh wrote:
> On 14/11/16 19:07, Zygo Blaxell wrote:
> >There is also a still-unresolved problem where the filesystem CPU usage
> >rises exponentially for some operations depending on the number of shared
> >references to an extent. Files which contain blocks with more than a few
> >thousand shared references can trigger this problem. A file over 1TB can
> >keep the kernel busy at 100% CPU for over 40 minutes at a time.
>
> Yes, I see this all the time. For my use cases, I don't really care about
> "shared references" as blocks of files, but am happy to simply deduplicate
> at the whole-file level. I wonder if this still will have the same effect,
> however. I guess that this could be mitigated in a tool, but this is going
> to be both annoying and not the most elegant solution.
If you have huge files (1TB+) this can be a problem even with whole-file
deduplications (which are really just extent-level deduplications applied
to the entire file). The CPU time is a product of file size and extent
reference count with some other multipliers on top.
I've hacked around it by timing how long it takes to manipulate the data,
and blacklisting any hash value or block address that takes more than
10 seconds to process (if such a block is found after blacklisting, just
skip processing the block/extent/file entirely). It turns out there are
very few of these in practice (only a few hundred per TB) but these few
hundred block hash values occur millions of times in a large data corpus.
> One thing I am keen to understand is if BTRFS will automatically ignore a
> request to deduplicate a file if it is already deduplicated? Given the
> performance I see when doing a repeat deduplication, it seems to me that it
> can't be doing so, although this could be caused by the CPU usage you
> mention above.
As far as I can tell btrfs doesn't do anything different in this
case--it'll happily repeat the entire lock/read/compare/delete/insert
sequence even if the outcome cannot be different from the initial
conditions. Due to limitations of VFS caching it'll read the same blocks
from storage hardware twice, too.
> In any case, I'm considering some digging into the filesystem structures to
> see if I can work this out myself before i do any deduplication. I'm fairly
> sure this should be relatively simple to work out, at least well enough for
> my purposes.
I used FIEMAP (then later replaced it with SEARCH_V2 for speed) to map
the extents to physical addresses before deduping them. If you're only
going to do whole-file dedup then you only need to care about the physical
address of the first non-hole extent.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v9 1/5] mfd: mxs-lradc: Add support for mxs-lradc MFD
From: Marek Vasut @ 2016-11-14 18:43 UTC (permalink / raw)
To: Ksenija Stanojevic, linux-kernel
Cc: lee.jones, dmitry.torokhov, linux-input, jic23, knaack.h, lars,
pmeerw, linux-iio, harald, stefan.wahren, fabio.estevam
In-Reply-To: <c18883dfacaaf40ab98cbb4938d5164a95a817d7.1478071676.git.ksenija.stanojevic@gmail.com>
On 11/02/2016 08:38 AM, Ksenija Stanojevic wrote:
> Add core files for low resolution analog-to-digital converter (mxs-lradc)
> MFD driver.
>
> Signed-off-by: Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
> ---
> Changes in v9:
> - improve commit message.
>
> Changes in v8:
> - rebase onto 4.9-rc1
>
> Changes in v7:
> - define macros ADC_CELL and TSC_CELL
> - remove one cell and dynamically set them in the switch()
> - fail in the touchscreen driver instead of mfd driver if
> hardware doesn't contain a touchscreen
>
> Changes in v6:
> - update copyright
> - add kernel-doc header for struct mxs-lradc
> - add error message
> - change EINVAL to ENODEV
> - use PLATFORM_DEVID_NONE instead -1
> - cosmetic fixes
>
> Changes in v5:
> - use DEFINE_RES_MEM
> - don't pass ioreammaped adress to platform cells
> - move comment outside of struct mxs_lradc
> - change type of argument in mxs_lradc_reg_set, mxs_lradc_reg_clear,
> mxs_lradc_reg_wrt (struct mxs_lradc * -> void __iomem *)
>
> Changes in v4:
> - update copyright
> - use DEFINE_RES_IRQ_NAMED
> - remove mxs_lradc_add_device function
> - use struct mfd_cell in static form
> - improve spacing
> - remove unnecessary comment
> - remove platform_get_irq
> - remove touch_ret and use ret instead
> - rename use_touchscreen to touchscreen_wire
> - use goto statements
> - remove irq[13], irq_count and irq_name from struct mxs_lradc
> - remove all defines from inside the struct definition
>
> Changes in v3:
> - add note to commit message
> - move switch statement into if(touch_ret == 0) branch
> - add MODULE_AUTHOR
>
> Changes in v2:
> - do not change spacing in Kconfig
> - make struct mfd_cell part of struct mxs_lradc
> - use switch instead of if in mxs_lradc_irq_mask
> - use only necessary header files in mxs_lradc.h
> - use devm_mfd_add_device
> - use separate function to register mfd device
> - change licence to GPL
> - add copyright
>
> drivers/mfd/Kconfig | 17 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/mxs-lradc.c | 249 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/mxs-lradc.h | 203 ++++++++++++++++++++++++++++++++++
> 4 files changed, 470 insertions(+)
> create mode 100644 drivers/mfd/mxs-lradc.c
> create mode 100644 include/linux/mfd/mxs-lradc.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index c6df644..bdd88cf 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -326,6 +326,23 @@ config MFD_MC13XXX_I2C
> help
> Select this if your MC13xxx is connected via an I2C bus.
>
> +config MFD_MXS_LRADC
> + tristate "Freescale i.MX23/i.MX28 LRADC"
> + depends on ARCH_MXS || COMPILE_TEST
> + select MFD_CORE
> + select STMP_DEVICE
> + help
> + Say yes here to build support for the Low Resolution
> + Analog-to-Digital Converter (LRADC) found on the i.MX23 and i.MX28
> + processors. This driver provides common support for accessing the
> + device, additional drivers must be enabled in order to use the
> + functionality of the device:
> + mxs-lradc-adc for ADC readings
> + mxs-lradc-ts for touchscreen support
> +
> + This driver can also be built as a module. If so, the module will be
> + called mxs-lradc.
> +
> config MFD_MX25_TSADC
> tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
> select REGMAP_MMIO
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9834e66..057ca15 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -211,3 +211,4 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
>
> obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> +obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o
> diff --git a/drivers/mfd/mxs-lradc.c b/drivers/mfd/mxs-lradc.c
> new file mode 100644
> index 0000000..ffc8f2e
> --- /dev/null
> +++ b/drivers/mfd/mxs-lradc.c
> @@ -0,0 +1,249 @@
> +/*
> + * Freescale MXS Low Resolution Analog-to-Digital Converter driver
> + *
> + * Copyright (c) 2012 DENX Software Engineering, GmbH.
> + * Copyright (c) 2016 Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
> + *
> + * Authors:
> + * Marek Vasut <marex@denx.de>
> + * Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/device.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/mxs-lradc.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +#define MXS_LRADC_BASE 0x80050000
Just for my understanding, why is this hardware address hard-coded here?
Shouldn't that be fetched from DT ?
> +#define ADC_CELL 0
> +#define TSC_CELL 1
[...]
--
Best regards,
Marek Vasut
^ permalink raw reply
* RE: [PATCH v2] libsepol: fix checkpolicy dontaudit compiler bug
From: Roberts, William C @ 2016-11-14 18:43 UTC (permalink / raw)
To: Stephen Smalley, selinux@tycho.nsa.gov
In-Reply-To: <1479145685-4899-1-git-send-email-sds@tycho.nsa.gov>
> -----Original Message-----
> From: Selinux [mailto:selinux-bounces@tycho.nsa.gov] On Behalf Of Stephen
> Smalley
> Sent: Monday, November 14, 2016 9:48 AM
> To: selinux@tycho.nsa.gov
> Cc: Stephen Smalley <sds@tycho.nsa.gov>
> Subject: [PATCH v2] libsepol: fix checkpolicy dontaudit compiler bug
>
> The combining logic for dontaudit rules was wrong, causing a dontaudit A B:C *;
> rule to be clobbered by a dontaudit A B:C p; rule.
>
> Reported-by: Nick Kralevich <nnk@google.com>
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> libsepol/src/expand.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/libsepol/src/expand.c b/libsepol/src/expand.c index 004a029..d7adbf8
> 100644
> --- a/libsepol/src/expand.c
> +++ b/libsepol/src/expand.c
> @@ -1604,7 +1604,8 @@ static int expand_range_trans(expand_state_t * state,
> static avtab_ptr_t find_avtab_node(sepol_handle_t * handle,
> avtab_t * avtab, avtab_key_t * key,
> cond_av_list_t ** cond,
> - av_extended_perms_t *xperms)
> + av_extended_perms_t *xperms,
> + char *alloced)
> {
> avtab_ptr_t node;
> avtab_datum_t avdatum;
> @@ -1658,6 +1659,11 @@ static avtab_ptr_t find_avtab_node(sepol_handle_t *
> handle,
> nl->next = *cond;
> *cond = nl;
> }
> + if (alloced)
> + *alloced = 1;
> + } else {
> + if (alloced)
> + *alloced = 0;
> }
>
> return node;
> @@ -1750,7 +1756,7 @@ static int expand_terule_helper(sepol_handle_t *
> handle,
> return EXPAND_RULE_CONFLICT;
> }
>
> - node = find_avtab_node(handle, avtab, &avkey, cond, NULL);
> + node = find_avtab_node(handle, avtab, &avkey, cond, NULL,
> NULL);
> if (!node)
> return -1;
> if (enabled) {
> @@ -1790,6 +1796,7 @@ static int expand_avrule_helper(sepol_handle_t *
> handle,
> class_perm_node_t *cur;
> uint32_t spec = 0;
> unsigned int i;
> + char alloced;
>
> if (specified & AVRULE_ALLOWED) {
> spec = AVTAB_ALLOWED;
> @@ -1824,7 +1831,8 @@ static int expand_avrule_helper(sepol_handle_t *
> handle,
> avkey.target_class = cur->tclass;
> avkey.specified = spec;
>
> - node = find_avtab_node(handle, avtab, &avkey, cond,
> extended_perms);
> + node = find_avtab_node(handle, avtab, &avkey, cond,
> + extended_perms, &alloced);
> if (!node)
> return EXPAND_RULE_ERROR;
> if (enabled) {
> @@ -1850,7 +1858,7 @@ static int expand_avrule_helper(sepol_handle_t *
> handle,
> */
> avdatump->data &= cur->data;
> } else if (specified & AVRULE_DONTAUDIT) {
> - if (avdatump->data)
> + if (!alloced)
> avdatump->data &= ~cur->data;
> else
> avdatump->data = ~cur->data;
This seems awkward to me. If the insertion created a new empty node
why wouldn't !avdump->data be true (note the addition of the not operator)?
Or perhaps a mechanism to actual set the data on allocation, this way the logic is
Just &=.
> --
> 2.7.4
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
^ permalink raw reply
* [PATCH v2 6/6] btrfs-progs: document space_cache=v2 more thoroughly
From: Omar Sandoval @ 2016-11-14 18:43 UTC (permalink / raw)
To: linux-btrfs; +Cc: kernel-team
In-Reply-To: <cover.1479148594.git.osandov@fb.com>
From: Omar Sandoval <osandov@fb.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
Documentation/btrfs-man5.asciidoc | 43 +++++++++++++++++++++++----------------
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/Documentation/btrfs-man5.asciidoc b/Documentation/btrfs-man5.asciidoc
index d12b059..3b003d3 100644
--- a/Documentation/btrfs-man5.asciidoc
+++ b/Documentation/btrfs-man5.asciidoc
@@ -319,25 +319,32 @@ May be resumed with *btrfs balance resume* or the paused state can be removed
by *btrfs balance cancel*. The default behaviour is to start interrutpd balance.
*space_cache*::
-*space_cache=v2*::
+*space_cache='version'*::
*nospace_cache*::
-('nospace_cache' since: 3.2, 'space_cache=v2' since 4.5, default: on)
-+
-Options to control the free space cache. This affects performance as searching
-for new free blocks could take longer if the space cache is not enabled. On the
-other hand, managing the space cache consumes some resources. It can be
-disabled without clearing at mount time.
-+
-There are two implementations of how the space is tracked. The safe default is
-'v1'. On large filesystems (many-terabytes) and certain workloads the 'v1'
-performance may degrade. This problem is addressed by 'v2', that is based on
-b-trees, sometimes referred to as 'free-space-tree'.
-+
-'Compatibility notes:'
-+
-* the 'v2' has to be enabled manually at mount time, once
-* kernel without 'v2' support will be able to mount the filesystem in read-only mode
-* 'v2' can be removed by mounting with 'clear_cache'
+('nospace_cache' since: 3.2, 'space_cache=v1' and 'space_cache=v2' since 4.5, default: 'space_cache=v1')
++
+Options to control the free space cache. The free space cache greatly improves
+performance when reading block group free space into memory. However, managing
+the space cache consumes some resources, including a small amount of disk
+space.
++
+There are two implementations of the free space cache. The original
+implementation, 'v1', is the safe default. The 'v1' space cache can be disabled
+at mount time with 'nospace_cache' without clearing.
++
+On very large filesystems (many terabytes) and certain workloads, the
+performance of the 'v1' space cache may degrade drastically. The 'v2'
+implementation, which adds a new B-tree called the free space tree, addresses
+this issue. Once enabled, the 'v2' space cache will always be used and cannot
+be disabled unless it is cleared. Use 'clear_cache,space_cache=v1' or
+'clear_cache,nospace_cache' to do so. If 'v2' is enabled, kernels without 'v2'
+support will only be able to mount the filesystem in read-only mode. The
+`btrfs(8)` command currently only has read-only support for 'v2'. A read-write
+command may be run on a 'v2' filesystem by clearing the cache, running the
+command, and then remounting with 'space_cache=v2'.
++
+If a version is not explicitly specified, the default implementation will be
+chosen, which is 'v1' as of 4.9.
*ssd*::
*nossd*::
--
2.10.2
^ permalink raw reply related
* [PATCH v2 5/6] btrfs-progs: implement btrfs check --clear-space-cache v2
From: Omar Sandoval @ 2016-11-14 18:43 UTC (permalink / raw)
To: linux-btrfs; +Cc: kernel-team
In-Reply-To: <cover.1479148594.git.osandov@fb.com>
From: Omar Sandoval <osandov@fb.com>
Reviewed-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
Documentation/btrfs-check.asciidoc | 14 +++++++++-----
cmds-check.c | 34 +++++++++++++++++++++++++---------
2 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/Documentation/btrfs-check.asciidoc b/Documentation/btrfs-check.asciidoc
index 5ef414e..633cbbf 100644
--- a/Documentation/btrfs-check.asciidoc
+++ b/Documentation/btrfs-check.asciidoc
@@ -80,12 +80,16 @@ superblock is damaged.
--clear-space-cache v1|v2::
completely wipe all free space cache of given type
-
-NOTE: Only v1 free space cache supported is implemented.
+
-Kernel mount option 'clear_cache' is only designed to rebuild free space cache
-which is modified during the lifetime of that mount option. It doesn't rebuild
-all free space cache, nor clear them out.
+For free space cache 'v1', the 'clear_cache' kernel mount option only rebuilds
+the free space cache for block groups that are modified while the filesystem is
+mounted with that option. Thus, using this option with 'v1' makes it possible
+to actually clear the entire free space cache.
++
+For free space cache 'v2', the 'clear_cache' kernel mount option does destroy
+the entire free space cache. This option with 'v2' provides an alternative
+method of clearing the free space cache that doesn't require mounting the
+filesystem.
DANGEROUS OPTIONS
diff --git a/cmds-check.c b/cmds-check.c
index 57c4300..0eca102 100644
--- a/cmds-check.c
+++ b/cmds-check.c
@@ -11170,7 +11170,6 @@ const char * const cmd_check_usage[] = {
"--chunk-root <bytenr> use the given bytenr for the chunk tree root",
"-p|--progress indicate progress",
"--clear-space-cache v1|v2 clear space cache for v1 or v2",
- " NOTE: v1 support implemented",
NULL
};
@@ -11292,13 +11291,16 @@ int cmd_check(int argc, char **argv)
}
break;
case GETOPT_VAL_CLEAR_SPACE_CACHE:
- if (strcmp(optarg, "v1") != 0) {
- error(
- "only v1 support implmented, unrecognized value %s",
- optarg);
+ if (strcmp(optarg, "v1") == 0) {
+ clear_space_cache = 1;
+ } else if (strcmp(optarg, "v2") == 0) {
+ clear_space_cache = 2;
+ ctree_flags |= OPEN_CTREE_INVALIDATE_FST;
+ } else {
+ error("invalid argument to --clear-space-cache; "
+ "must be v1 or v2");
exit(1);
}
- clear_space_cache = 1;
ctree_flags |= OPEN_CTREE_WRITES;
break;
}
@@ -11352,11 +11354,10 @@ int cmd_check(int argc, char **argv)
global_info = info;
root = info->fs_root;
- if (clear_space_cache) {
+ if (clear_space_cache == 1) {
if (btrfs_fs_compat_ro(info,
BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE)) {
- error(
- "free space cache v2 detected, clearing not implemented");
+ error("free space cache v2 detected; use --clear-space-cache v2");
ret = 1;
goto close_out;
}
@@ -11369,6 +11370,21 @@ int cmd_check(int argc, char **argv)
printf("Free space cache cleared\n");
}
goto close_out;
+ } else if (clear_space_cache == 2) {
+ if (!btrfs_fs_compat_ro(info, BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE)) {
+ printf("No free space cache v2 to clear\n");
+ ret = 0;
+ goto close_out;
+ }
+ printf("Clear free space cache v2\n");
+ ret = btrfs_clear_free_space_tree(info);
+ if (ret) {
+ error("Failed to clear free space cache v2");
+ ret = 1;
+ } else {
+ printf("Free space cache v2 cleared\n");
+ }
+ goto close_out;
}
/*
--
2.10.2
^ permalink raw reply related
* [PATCH v2 4/6] btrfs-progs: add btrfs_clear_free_space_tree() from the kernel
From: Omar Sandoval @ 2016-11-14 18:43 UTC (permalink / raw)
To: linux-btrfs; +Cc: kernel-team
In-Reply-To: <cover.1479148594.git.osandov@fb.com>
From: Omar Sandoval <osandov@fb.com>
Reviewed-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
ctree.h | 6 ++++
extent-tree.c | 11 +++++++
free-space-tree.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
free-space-tree.h | 1 +
root-tree.c | 25 +++++++++++++++
5 files changed, 134 insertions(+)
diff --git a/ctree.h b/ctree.h
index d67b852..b433bca 100644
--- a/ctree.h
+++ b/ctree.h
@@ -2504,6 +2504,10 @@ int btrfs_inc_ref(struct btrfs_trans_handle *trans, struct btrfs_root *root,
struct extent_buffer *buf, int record_parent);
int btrfs_dec_ref(struct btrfs_trans_handle *trans, struct btrfs_root *root,
struct extent_buffer *buf, int record_parent);
+int btrfs_free_tree_block(struct btrfs_trans_handle *trans,
+ struct btrfs_root *root,
+ struct extent_buffer *buf,
+ u64 parent, int last_ref);
int btrfs_free_extent(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
u64 bytenr, u64 num_bytes, u64 parent,
@@ -2664,6 +2668,8 @@ int btrfs_add_root_ref(struct btrfs_trans_handle *trans,
int btrfs_insert_root(struct btrfs_trans_handle *trans, struct btrfs_root
*root, struct btrfs_key *key, struct btrfs_root_item
*item);
+int btrfs_del_root(struct btrfs_trans_handle *trans, struct btrfs_root *root,
+ struct btrfs_key *key);
int btrfs_update_root(struct btrfs_trans_handle *trans, struct btrfs_root
*root, struct btrfs_key *key, struct btrfs_root_item
*item);
diff --git a/extent-tree.c b/extent-tree.c
index 3b1577e..b52c515 100644
--- a/extent-tree.c
+++ b/extent-tree.c
@@ -2467,6 +2467,17 @@ static int del_pending_extents(struct btrfs_trans_handle *trans, struct
return err;
}
+
+int btrfs_free_tree_block(struct btrfs_trans_handle *trans,
+ struct btrfs_root *root,
+ struct extent_buffer *buf,
+ u64 parent, int last_ref)
+{
+ return btrfs_free_extent(trans, root, buf->start, buf->len, parent,
+ root->root_key.objectid,
+ btrfs_header_level(buf), 0);
+}
+
/*
* remove an extent from the root, returns 0 on success
*/
diff --git a/free-space-tree.c b/free-space-tree.c
index 3c7a246..b9e21f7 100644
--- a/free-space-tree.c
+++ b/free-space-tree.c
@@ -20,6 +20,7 @@
#include "disk-io.h"
#include "free-space-cache.h"
#include "free-space-tree.h"
+#include "transaction.h"
static struct btrfs_free_space_info *
search_free_space_info(struct btrfs_trans_handle *trans,
@@ -67,6 +68,96 @@ static int free_space_test_bit(struct btrfs_block_group_cache *block_group,
return !!extent_buffer_test_bit(leaf, ptr, i);
}
+static int clear_free_space_tree(struct btrfs_trans_handle *trans,
+ struct btrfs_root *root)
+{
+ struct btrfs_path *path;
+ struct btrfs_key key;
+ int nr;
+ int ret;
+
+ path = btrfs_alloc_path();
+ if (!path)
+ return -ENOMEM;
+
+ key.objectid = 0;
+ key.type = 0;
+ key.offset = 0;
+
+ while (1) {
+ ret = btrfs_search_slot(trans, root, &key, path, -1, 1);
+ if (ret < 0)
+ goto out;
+
+ nr = btrfs_header_nritems(path->nodes[0]);
+ if (!nr)
+ break;
+
+ path->slots[0] = 0;
+ ret = btrfs_del_items(trans, root, path, 0, nr);
+ if (ret)
+ goto out;
+
+ btrfs_release_path(path);
+ }
+
+ ret = 0;
+out:
+ btrfs_free_path(path);
+ return ret;
+}
+
+int btrfs_clear_free_space_tree(struct btrfs_fs_info *fs_info)
+{
+ struct btrfs_trans_handle *trans;
+ struct btrfs_root *tree_root = fs_info->tree_root;
+ struct btrfs_root *free_space_root = fs_info->free_space_root;
+ int ret;
+ u64 features;
+
+ trans = btrfs_start_transaction(tree_root, 0);
+ if (IS_ERR(trans))
+ return PTR_ERR(trans);
+
+
+ features = btrfs_super_compat_ro_flags(fs_info->super_copy);
+ features &= ~(BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE_VALID |
+ BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE);
+ btrfs_set_super_compat_ro_flags(fs_info->super_copy, features);
+ fs_info->free_space_root = NULL;
+
+ ret = clear_free_space_tree(trans, free_space_root);
+ if (ret)
+ goto abort;
+
+ ret = btrfs_del_root(trans, tree_root, &free_space_root->root_key);
+ if (ret)
+ goto abort;
+
+ list_del(&free_space_root->dirty_list);
+
+ ret = clean_tree_block(trans, tree_root, free_space_root->node);
+ if (ret)
+ goto abort;
+ ret = btrfs_free_tree_block(trans, free_space_root,
+ free_space_root->node, 0, 1);
+ if (ret)
+ goto abort;
+
+ free_extent_buffer(free_space_root->node);
+ free_extent_buffer(free_space_root->commit_root);
+ kfree(free_space_root);
+
+ ret = btrfs_commit_transaction(trans, tree_root);
+ if (ret)
+ return ret;
+
+ return 0;
+
+abort:
+ return ret;
+}
+
static int load_free_space_bitmaps(struct btrfs_fs_info *fs_info,
struct btrfs_block_group_cache *block_group,
struct btrfs_path *path,
diff --git a/free-space-tree.h b/free-space-tree.h
index 7529a46..4845f13 100644
--- a/free-space-tree.h
+++ b/free-space-tree.h
@@ -19,6 +19,7 @@
#ifndef __BTRFS_FREE_SPACE_TREE_H__
#define __BTRFS_FREE_SPACE_TREE_H__
+int btrfs_clear_free_space_tree(struct btrfs_fs_info *fs_info);
int load_free_space_tree(struct btrfs_fs_info *fs_info,
struct btrfs_block_group_cache *block_group);
diff --git a/root-tree.c b/root-tree.c
index cca424e..ab01a14 100644
--- a/root-tree.c
+++ b/root-tree.c
@@ -143,6 +143,31 @@ int btrfs_insert_root(struct btrfs_trans_handle *trans, struct btrfs_root
return ret;
}
+/* drop the root item for 'key' from 'root' */
+int btrfs_del_root(struct btrfs_trans_handle *trans, struct btrfs_root *root,
+ struct btrfs_key *key)
+{
+ struct btrfs_path *path;
+ int ret;
+
+ path = btrfs_alloc_path();
+ if (!path)
+ return -ENOMEM;
+ ret = btrfs_search_slot(trans, root, key, path, -1, 1);
+ if (ret < 0)
+ goto out;
+
+ if (ret != 0) {
+ ret = -ENOENT;
+ goto out;
+ }
+
+ ret = btrfs_del_item(trans, root, path);
+out:
+ btrfs_free_path(path);
+ return ret;
+}
+
/*
* add a btrfs_root_ref item. type is either BTRFS_ROOT_REF_KEY
* or BTRFS_ROOT_BACKREF_KEY.
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/6] btrfs-progs: add OPEN_CTREE_INVALIDATE_FST flag
From: Omar Sandoval @ 2016-11-14 18:43 UTC (permalink / raw)
To: linux-btrfs; +Cc: kernel-team
In-Reply-To: <cover.1479148594.git.osandov@fb.com>
From: Omar Sandoval <osandov@fb.com>
If this flag is passed to open_ctree(), we'll clear the
FREE_SPACE_TREE_VALID compat_ro bit. The kernel will then reconstruct
the free space tree the next time the filesystem is mounted.
Reviewed-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
chunk-recover.c | 2 +-
disk-io.c | 29 +++++++++++++++++++----------
disk-io.h | 9 ++++++++-
3 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/chunk-recover.c b/chunk-recover.c
index e33ee8b..e6b26ac 100644
--- a/chunk-recover.c
+++ b/chunk-recover.c
@@ -1477,7 +1477,7 @@ open_ctree_with_broken_chunk(struct recover_control *rc)
memcpy(fs_info->fsid, &disk_super->fsid, BTRFS_FSID_SIZE);
- ret = btrfs_check_fs_compatibility(disk_super, 1);
+ ret = btrfs_check_fs_compatibility(disk_super, OPEN_CTREE_WRITES);
if (ret)
goto out_devices;
diff --git a/disk-io.c b/disk-io.c
index a576300..de25fcd 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -904,7 +904,8 @@ free_all:
return NULL;
}
-int btrfs_check_fs_compatibility(struct btrfs_super_block *sb, int writable)
+int btrfs_check_fs_compatibility(struct btrfs_super_block *sb,
+ unsigned int flags)
{
u64 features;
@@ -923,13 +924,22 @@ int btrfs_check_fs_compatibility(struct btrfs_super_block *sb, int writable)
btrfs_set_super_incompat_flags(sb, features);
}
- features = btrfs_super_compat_ro_flags(sb) &
- ~BTRFS_FEATURE_COMPAT_RO_SUPP;
- if (writable && features) {
- printk("couldn't open RDWR because of unsupported "
- "option features (%Lx).\n",
- (unsigned long long)features);
- return -ENOTSUP;
+ features = btrfs_super_compat_ro_flags(sb);
+ if (flags & OPEN_CTREE_WRITES) {
+ if (flags & OPEN_CTREE_INVALIDATE_FST) {
+ /* Clear the FREE_SPACE_TREE_VALID bit on disk... */
+ features &= ~BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE_VALID;
+ btrfs_set_super_compat_ro_flags(sb, features);
+ /* ... and ignore the free space tree bit. */
+ features &= ~BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE;
+ }
+ if (features & ~BTRFS_FEATURE_COMPAT_RO_SUPP) {
+ printk("couldn't open RDWR because of unsupported "
+ "option features (%Lx).\n",
+ (unsigned long long)features);
+ return -ENOTSUP;
+ }
+
}
return 0;
}
@@ -1320,8 +1330,7 @@ static struct btrfs_fs_info *__open_ctree_fd(int fp, const char *path,
memcpy(fs_info->fsid, &disk_super->fsid, BTRFS_FSID_SIZE);
- ret = btrfs_check_fs_compatibility(fs_info->super_copy,
- flags & OPEN_CTREE_WRITES);
+ ret = btrfs_check_fs_compatibility(fs_info->super_copy, flags);
if (ret)
goto out_devices;
diff --git a/disk-io.h b/disk-io.h
index 8ab36aa..d4a0e7f 100644
--- a/disk-io.h
+++ b/disk-io.h
@@ -74,6 +74,12 @@ enum btrfs_open_ctree_flags {
/* Allow to open a partially created filesystem */
OPEN_CTREE_FS_PARTIAL = (1U << 12),
+
+ /*
+ * Invalidate the free space tree (i.e., clear the FREE_SPACE_TREE_VALID
+ * compat_ro bit).
+ */
+ OPEN_CTREE_INVALIDATE_FST = (1U << 13),
};
/*
@@ -128,7 +134,8 @@ int clean_tree_block(struct btrfs_trans_handle *trans,
void btrfs_free_fs_info(struct btrfs_fs_info *fs_info);
struct btrfs_fs_info *btrfs_new_fs_info(int writable, u64 sb_bytenr);
-int btrfs_check_fs_compatibility(struct btrfs_super_block *sb, int writable);
+int btrfs_check_fs_compatibility(struct btrfs_super_block *sb,
+ unsigned int flags);
int btrfs_setup_all_roots(struct btrfs_fs_info *fs_info, u64 root_tree_bytenr,
unsigned flags);
void btrfs_release_all_roots(struct btrfs_fs_info *fs_info);
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/6] btrfs-progs: format FREE_SPACE_TREE{,_VALID} nicely in dump-super
From: Omar Sandoval @ 2016-11-14 18:43 UTC (permalink / raw)
To: linux-btrfs; +Cc: kernel-team
In-Reply-To: <cover.1479148594.git.osandov@fb.com>
From: Omar Sandoval <osandov@fb.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
cmds-inspect-dump-super.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/cmds-inspect-dump-super.c b/cmds-inspect-dump-super.c
index d9f7bfb..ba0d708 100644
--- a/cmds-inspect-dump-super.c
+++ b/cmds-inspect-dump-super.c
@@ -197,6 +197,16 @@ struct readable_flag_entry {
char *output;
};
+#define DEF_COMPAT_RO_FLAG_ENTRY(bit_name) \
+ {BTRFS_FEATURE_COMPAT_RO_##bit_name, #bit_name}
+
+static struct readable_flag_entry compat_ro_flags_array[] = {
+ DEF_COMPAT_RO_FLAG_ENTRY(FREE_SPACE_TREE),
+ DEF_COMPAT_RO_FLAG_ENTRY(FREE_SPACE_TREE_VALID),
+};
+static const int compat_ro_flags_num = sizeof(compat_ro_flags_array) /
+ sizeof(struct readable_flag_entry);
+
#define DEF_INCOMPAT_FLAG_ENTRY(bit_name) \
{BTRFS_FEATURE_INCOMPAT_##bit_name, #bit_name}
@@ -268,6 +278,19 @@ static void __print_readable_flag(u64 flag, struct readable_flag_entry *array,
printf(")\n");
}
+static void print_readable_compat_ro_flag(u64 flag)
+{
+ /*
+ * We know about the FREE_SPACE_TREE{,_VALID} bits, but we don't
+ * actually support them yet.
+ */
+ return __print_readable_flag(flag, compat_ro_flags_array,
+ compat_ro_flags_num,
+ BTRFS_FEATURE_COMPAT_RO_SUPP |
+ BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE |
+ BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE_VALID);
+}
+
static void print_readable_incompat_flag(u64 flag)
{
return __print_readable_flag(flag, incompat_flags_array,
@@ -377,6 +400,7 @@ static void dump_superblock(struct btrfs_super_block *sb, int full)
(unsigned long long)btrfs_super_compat_flags(sb));
printf("compat_ro_flags\t\t0x%llx\n",
(unsigned long long)btrfs_super_compat_ro_flags(sb));
+ print_readable_compat_ro_flag(btrfs_super_compat_ro_flags(sb));
printf("incompat_flags\t\t0x%llx\n",
(unsigned long long)btrfs_super_incompat_flags(sb));
print_readable_incompat_flag(btrfs_super_incompat_flags(sb));
--
2.10.2
^ permalink raw reply related
* [PATCH v2 1/6] btrfs-progs: add the FREE_SPACE_TREE_VALID compat_ro bit definition
From: Omar Sandoval @ 2016-11-14 18:43 UTC (permalink / raw)
To: linux-btrfs; +Cc: kernel-team
In-Reply-To: <cover.1479148594.git.osandov@fb.com>
From: Omar Sandoval <osandov@fb.com>
This is just the definition; we don't support it yet.
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
ctree.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/ctree.h b/ctree.h
index d47f0ae..d67b852 100644
--- a/ctree.h
+++ b/ctree.h
@@ -467,6 +467,14 @@ struct btrfs_super_block {
* ones specified below then we will fail to mount
*/
#define BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE (1ULL << 0)
+/*
+ * Older kernels on big-endian systems produced broken free space tree bitmaps,
+ * and btrfs-progs also used to corrupt the free space tree. If this bit is
+ * clear, then the free space tree cannot be trusted. btrfs-progs can also
+ * intentionally clear this bit to ask the kernel to rebuild the free space
+ * tree.
+ */
+#define BTRFS_FEATURE_COMPAT_RO_FREE_SPACE_TREE_VALID (1ULL << 1)
#define BTRFS_FEATURE_INCOMPAT_MIXED_BACKREF (1ULL << 0)
#define BTRFS_FEATURE_INCOMPAT_DEFAULT_SUBVOL (1ULL << 1)
@@ -493,6 +501,11 @@ struct btrfs_super_block {
#define BTRFS_FEATURE_COMPAT_SUPP 0ULL
+/*
+ * The FREE_SPACE_TREE and FREE_SPACE_TREE_VALID compat_ro bits must not be
+ * added here until read-write support for the free space tree is implemented in
+ * btrfs-progs.
+ */
#define BTRFS_FEATURE_COMPAT_RO_SUPP 0ULL
#define BTRFS_FEATURE_INCOMPAT_SUPP \
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/6] btrfs-progs: better space_cache=v2 support
From: Omar Sandoval @ 2016-11-14 18:43 UTC (permalink / raw)
To: linux-btrfs; +Cc: kernel-team
From: Omar Sandoval <osandov@fb.com>
Hi,
Cover letter from v1:
This series implements some support for space_cache=v2 in btrfs-progs.
In particular, this adds support for `btrfs check --clear-space-cache v2`,
proper printing of the free space tree flags for `btrfs inspect-internal
dump-super`, and better documentation.
We'd previously talked about always making btrfs-progs always invalidate
the free space tree when doing write operations, but I decided that this
should be an action explicitly requested by the user. It'd also be
unsafe if using a kernel without the free space tree valid bit support,
which is why I didn't implement a `btrfs check --invalidate-free-space-cache`
option. Doing the full clear is always safe.
Still missing is full read-write support, but this should hopefully
cover most btrfs-progs usage.
Changes since v1:
- Change unsigned -> unsigned int argument to
btrfs_check_fs_compatability() in patch 3
- Remove BUG_ON() in btrfs_del_root() in patch 4
- Return error from btrfs_free_tree_block() in patch 4
- Handle errors from btrfs_free_tree_block() and clean_tree_block() in
patch 4
- Add Qu Wenruo's Reviewed-by to patches 3, 4, and 5
Thanks!
Omar Sandoval (6):
btrfs-progs: add the FREE_SPACE_TREE_VALID compat_ro bit definition
btrfs-progs: format FREE_SPACE_TREE{,_VALID} nicely in dump-super
btrfs-progs: add OPEN_CTREE_INVALIDATE_FST flag
btrfs-progs: add btrfs_clear_free_space_tree() from the kernel
btrfs-progs: implement btrfs check --clear-space-cache v2
btrfs-progs: document space_cache=v2 more thoroughly
Documentation/btrfs-check.asciidoc | 14 +++---
Documentation/btrfs-man5.asciidoc | 43 ++++++++++--------
chunk-recover.c | 2 +-
cmds-check.c | 34 ++++++++++----
cmds-inspect-dump-super.c | 24 ++++++++++
ctree.h | 19 ++++++++
disk-io.c | 29 +++++++-----
disk-io.h | 9 +++-
extent-tree.c | 11 +++++
free-space-tree.c | 91 ++++++++++++++++++++++++++++++++++++++
free-space-tree.h | 1 +
root-tree.c | 25 +++++++++++
12 files changed, 258 insertions(+), 44 deletions(-)
--
2.10.2
^ permalink raw reply
* Re: [PATCH v2 net-next 3/6] bpf: Refactor codes handling percpu map
From: Alexei Starovoitov @ 2016-11-14 18:43 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, David Miller, Alexei Starovoitov, Daniel Borkmann,
Kernel Team
In-Reply-To: <1478890511-1346984-4-git-send-email-kafai@fb.com>
On Fri, Nov 11, 2016 at 10:55:08AM -0800, Martin KaFai Lau wrote:
> Refactor the codes that populate the value
> of a htab_elem in a BPF_MAP_TYPE_PERCPU_HASH
> typed bpf_map.
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Marek Vasut @ 2016-11-14 18:42 UTC (permalink / raw)
To: Joel Stanley, Cédric Le Goater
Cc: linux-mtd, David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Cyrille Pitchen, devicetree, Rob Herring,
Mark Rutland
In-Reply-To: <CACPK8Xc=AcA=d+O++W07ki+KkCxA86EnXj7dqTRobTpb9WQbUw@mail.gmail.com>
On 11/11/2016 05:42 AM, Joel Stanley wrote:
> On Wed, Nov 9, 2016 at 9:12 PM, Cédric Le Goater <clg@kaod.org> wrote:
>> This driver adds mtd support for spi-nor attached to either or both of
>> the Firmware Memory Controller or the SPI Flash Controller (AST2400
>> only).
>>
>> The SMC controllers on the Aspeed AST2500 SoC are very similar to the
>> ones found on the AST2400. The differences are on the number of
>> supported flash modules and their default mappings in the SoC address
>> space.
>>
>> The Aspeed AST2500 has one SPI controller for the BMC firmware and two
>> for the host firmware. All controllers have now the same set of
>> registers compatible with the AST2400 FMC controller and the legacy
>> 'SMC' controller is fully gone.
>>
>> Each controller has a memory range on which it maps its flash module
>> slaves. Each slave is assigned a memory window for its mapping that
>> can be changed at bootime with the Segment Address Register.
>>
>> Each SPI flash slave can then be accessed in two modes: Command and
>> User. When in User mode, accesses to the memory segment of the slaves
>> are translated in SPI transfers. When in Command mode, the HW
>> generates the SPI commands automatically and the memory segment is
>> accessed as if doing a MMIO.
>>
>> Currently, only the User mode is supported. Command mode needs a
>> little more work to check that the memory window on the AHB bus fits
>> the module size.
>>
>> Based on previous work from Milton D. Miller II <miltonm@us.ibm.com>
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> Tested on:
>>
>> * OpenPOWER Palmetto (AST2400) with
>> FMC controller : n25q256a
>> SPI controller : mx25l25635e and n25q512ax3
>>
>> * Evaluation board (AST2500) with
>> FMC controller : w25q256
>> SPI controller : w25q256
>>
>> * OpenPOWER Witherspoon (AST2500) with
>> FMC controller : mx25l25635e * 2
>> SPI controller : mx66l1g45g
>
> It's also in use on the Zaius and Barreleye OpenBMC systems.
>
> In that respect, I would like to see this merged once it's deemed
> ready by the mtd maintainers. We can follow up with the extra features
> in future patches.
>
> I've reviewed and tested this as Cedric and Milton have developed it,
> so please add:
>
> Reviewed-by: Joel Stanley <joel@jms.id.au>
>
Thanks! I'll review the patch ASAP (this week).
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: Debugging Ethernet issues
From: Florian Fainelli @ 2016-11-14 18:42 UTC (permalink / raw)
To: Sebastian Frias, Mason, Andrew Lunn
Cc: netdev, Mans Rullgard, Sergei Shtylyov, Tom Lendacky, Zach Brown,
Shaohui Xie, Tim Beale, Brian Hill, Vince Bridgers,
Balakumaran Kannan, David S. Miller, Kirill Kapranov
In-Reply-To: <2187db98-dc5a-7a3c-7965-7ccbeffc0fa1@gmail.com>
On 11/14/2016 10:20 AM, Florian Fainelli wrote:
> On 11/14/2016 09:59 AM, Sebastian Frias wrote:
>> On 11/14/2016 06:32 PM, Florian Fainelli wrote:
>>> On 11/14/2016 07:33 AM, Mason wrote:
>>>> On 14/11/2016 15:58, Mason wrote:
>>>>
>>>>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
>>>>> vs
>>>>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
>>>>>
>>>>> I'm not sure whether "flow control" is relevant...
>>>>
>>>> Based on phy_print_status()
>>>> phydev->pause ? "rx/tx" : "off"
>>>> I added the following patch.
>>>>
>>>> diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c
>>>> index defc22a15f67..4e758c1cfa4e 100644
>>>> --- a/drivers/net/ethernet/aurora/nb8800.c
>>>> +++ b/drivers/net/ethernet/aurora/nb8800.c
>>>> @@ -667,6 +667,8 @@ static void nb8800_link_reconfigure(struct net_device *dev)
>>>> struct phy_device *phydev = priv->phydev;
>>>> int change = 0;
>>>>
>>>> + printk("%s from %pf\n", __func__, __builtin_return_address(0));
>>>> +
>>>> if (phydev->link) {
>>>> if (phydev->speed != priv->speed) {
>>>> priv->speed = phydev->speed;
>>>> @@ -1274,9 +1276,9 @@ static int nb8800_hw_init(struct net_device *dev)
>>>> nb8800_writeb(priv, NB8800_PQ2, val & 0xff);
>>>>
>>>> /* Auto-negotiate by default */
>>>> - priv->pause_aneg = true;
>>>> - priv->pause_rx = true;
>>>> - priv->pause_tx = true;
>>>> + priv->pause_aneg = false;
>>>> + priv->pause_rx = false;
>>>> + priv->pause_tx = false;
>>>>
>>>> nb8800_mc_init(dev, 0);
>>>>
>>>>
>>>> Connected to 1000 Mbps switch:
>>>>
>>>> # time udhcpc | while read LINE; do date; echo $LINE; done
>>>> Thu Jan 1 00:00:22 UTC 1970
>>>> udhcpc (v1.22.1) started
>>>> Thu Jan 1 00:00:22 UTC 1970
>>>> Sending discover...
>>>> [ 24.565346] nb8800_link_reconfigure from phy_state_machine
>>>> Thu Jan 1 00:00:25 UTC 1970
>>>> Sending discover...
>>>> [ 26.575402] nb8800_link_reconfigure from phy_state_machine
>>>> [ 26.580972] nb8800 26000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
>>>> Thu Jan 1 00:00:28 UTC 1970
>>>> Sending discover...
>>>> Thu Jan 1 00:00:29 UTC 1970
>>>> Sending select for 172.27.64.58...
>>>> Thu Jan 1 00:00:29 UTC 1970
>>>> Lease of 172.27.64.58 obtained, lease time 604800
>>>> Thu Jan 1 00:00:29 UTC 1970
>>>> deleting routers
>>>> Thu Jan 1 00:00:29 UTC 1970
>>>> adding dns 172.27.0.17
>>>>
>>>> real 0m7.388s
>>>> user 0m0.040s
>>>> sys 0m0.090s
>>>>
>>>>
>>>>
>>>> Connected to 100 Mbps switch:
>>>>
>>>> # time udhcpc | while read LINE; do date; echo $LINE; done
>>>> Thu Jan 1 00:00:14 UTC 1970
>>>> udhcpc (v1.22.1) started
>>>> Thu Jan 1 00:00:15 UTC 1970
>>>> Sending discover...
>>>> [ 16.968621] nb8800_link_reconfigure from phy_state_machine
>>>> [ 17.975359] nb8800_link_reconfigure from phy_state_machine
>>>> [ 17.980923] nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
>>>> Thu Jan 1 00:00:18 UTC 1970
>>>> Sending discover...
>>>> Thu Jan 1 00:00:19 UTC 1970
>>>> Sending select for 172.27.64.58...
>>>> Thu Jan 1 00:00:19 UTC 1970
>>>> Lease of 172.27.64.58 obtained, lease time 604800
>>>> Thu Jan 1 00:00:19 UTC 1970
>>>> deleting routers
>>>> Thu Jan 1 00:00:19 UTC 1970
>>>> adding dns 172.27.0.17
>>>>
>>>> real 0m4.355s
>>>> user 0m0.043s
>>>> sys 0m0.083s
>>>>
>>>
>>> And the time difference is clearly accounted for auto-negotiation time
>>> here, as you can see it takes about 3 seconds for Gigabit Ethernet to
>>> auto-negotiate and that seems completely acceptable and normal to me
>>> since it is a more involved process than lower speeds.
>>>
>>>>
>>>>
>>>> OK, so now it works (by accident?) even on 100 Mbps switch, but it still
>>>> prints "flow control rx/tx"...
>>>
>>> Because your link partner advertises flow control, and that's what
>>> phydev->pause and phydev->asym_pause report (I know it's confusing, but
>>> that's what it is at the moment).
>>
>> Thanks.
>> Could you confirm that Mason's patch is correct and/or that it does not
>> has negative side-effects?
>
> The patch is not correct nor incorrect per-se, it changes the default
> policy of having pause frames advertised by default to not having them
> advertised by default. This influences both your Ethernet MAC and the
> link partner in that the result is either flow control is enabled
> (before) or it is not (with the patch). There must be something amiss if
> you see packet loss or some kind of problem like that with an early
> exchange such as DHCP. Flow control tend to kick in under higher packet
> rates (at least, that's what you expect).
>
>
>>
>> Right now we know that Mason's patch makes this work, but we do not understand
>> why nor its implications.
>
> You need to understand why, right now, the way this problem is
> presented, you came up with a workaround, not with the root cause or the
> solution. What does your link partner (switch?) reports, that is, what
> is the ethtool output when you have a link up from your nb8800 adapter?
Actually, nb8800_pause_config() seems to be doing a complete MAC/DMA
reconfiguration when pause frames get auto-negotiated while the link is
UP, and it does not differentiate being called from
ethtool::set_pauseparam or the PHYLIB adjust_link callback (which it
probably should), wondering if there is a not a remote chance you can
get the reply to arrive right when you just got signaled a link UP?
--
Florian
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Marek Vasut @ 2016-11-14 18:42 UTC (permalink / raw)
To: Joel Stanley, Cédric Le Goater
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse,
Brian Norris, Boris Brezillon, Richard Weinberger,
Cyrille Pitchen, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Mark Rutland
In-Reply-To: <CACPK8Xc=AcA=d+O++W07ki+KkCxA86EnXj7dqTRobTpb9WQbUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/11/2016 05:42 AM, Joel Stanley wrote:
> On Wed, Nov 9, 2016 at 9:12 PM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
>> This driver adds mtd support for spi-nor attached to either or both of
>> the Firmware Memory Controller or the SPI Flash Controller (AST2400
>> only).
>>
>> The SMC controllers on the Aspeed AST2500 SoC are very similar to the
>> ones found on the AST2400. The differences are on the number of
>> supported flash modules and their default mappings in the SoC address
>> space.
>>
>> The Aspeed AST2500 has one SPI controller for the BMC firmware and two
>> for the host firmware. All controllers have now the same set of
>> registers compatible with the AST2400 FMC controller and the legacy
>> 'SMC' controller is fully gone.
>>
>> Each controller has a memory range on which it maps its flash module
>> slaves. Each slave is assigned a memory window for its mapping that
>> can be changed at bootime with the Segment Address Register.
>>
>> Each SPI flash slave can then be accessed in two modes: Command and
>> User. When in User mode, accesses to the memory segment of the slaves
>> are translated in SPI transfers. When in Command mode, the HW
>> generates the SPI commands automatically and the memory segment is
>> accessed as if doing a MMIO.
>>
>> Currently, only the User mode is supported. Command mode needs a
>> little more work to check that the memory window on the AHB bus fits
>> the module size.
>>
>> Based on previous work from Milton D. Miller II <miltonm-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>>
>> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
>> ---
>> Tested on:
>>
>> * OpenPOWER Palmetto (AST2400) with
>> FMC controller : n25q256a
>> SPI controller : mx25l25635e and n25q512ax3
>>
>> * Evaluation board (AST2500) with
>> FMC controller : w25q256
>> SPI controller : w25q256
>>
>> * OpenPOWER Witherspoon (AST2500) with
>> FMC controller : mx25l25635e * 2
>> SPI controller : mx66l1g45g
>
> It's also in use on the Zaius and Barreleye OpenBMC systems.
>
> In that respect, I would like to see this merged once it's deemed
> ready by the mtd maintainers. We can follow up with the extra features
> in future patches.
>
> I've reviewed and tested this as Cedric and Milton have developed it,
> so please add:
>
> Reviewed-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
>
Thanks! I'll review the patch ASAP (this week).
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v9 1/5] mfd: mxs-lradc: Add support for mxs-lradc MFD
From: Ksenija Stanojević @ 2016-11-14 18:41 UTC (permalink / raw)
To: Stefan Wahren
Cc: Lee Jones, linux-input, Peter Meerwald-Stadler, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Dmitry Torokhov, Harald Geyer,
Fabio Estevam, linux-iio, Marek Vasut, linux-kernel
In-Reply-To: <1401051818.290769.fabb549c-29f9-4e5c-a868-650c6df97a1d.open-xchange@email.1und1.de>
Hi,
On Tue, Nov 8, 2016 at 11:34 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
> > Ksenija Stanojevic <ksenija.stanojevic@gmail.com> hat am 2. November 2016 um
> > 08:38 geschrieben:
> >
> >
> > Add core files for low resolution analog-to-digital converter (mxs-lradc)
> > MFD driver.
> >
> > Signed-off-by: Ksenija Stanojevic <ksenija.stanojevic@gmail.com>
>
> Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
>
> for Patch 1 + 2
>
> > ---
> > ...
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 9834e66..057ca15 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -211,3 +211,4 @@ obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> > obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> >
> > obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> > +obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o
>
> Btw this part won't apply anymore
I think now everyone is approving of this patch series.
Who will take this patch series, Jonathan or Lee?
Should I resend patches?
Thanks,
Ksenija
^ permalink raw reply
* Re: [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Laura Abbott @ 2016-11-14 18:41 UTC (permalink / raw)
To: Catalin Marinas, Mark Rutland
Cc: Ard Biesheuvel, x86, Will Deacon, linux-kernel, linux-mm,
Ingo Molnar, H. Peter Anvin, Joonsoo Kim, Thomas Gleixner,
Andrew Morton, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20161114181937.GG3096@e104818-lin.cambridge.arm.com>
On 11/14/2016 10:19 AM, Catalin Marinas wrote:
> On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
>> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
>>> On 11/02/2016 04:52 PM, Mark Rutland wrote:
>>>> On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
>>>>>
>>>>> __pa_symbol is technically the marco that should be used for kernel
>>>>> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
>>>>
>>>> Nit: s/marco/macro/
>>>>
>>>> I see there are some other uses of __pa() that look like they could/should be
>>>> __pa_symbol(), e.g. in mark_rodata_ro().
>>>>
>>>> I guess strictly speaking those need to be updated to? Or is there a reason
>>>> that we should not?
>>>
>>> If the concept of __pa_symbol is okay then yes I think all uses of __pa
>>> should eventually be converted for consistency and debugging.
>>
>> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
>> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
>> for consistency with other architectures.
>
> At a quick grep, it seems to only be used by mips and x86 and a single
> place in mm/memblock.c.
>
> Since we haven't seen any issues on arm/arm64 without this macro, can we
> not just continue to use __pa()?
Technically yes but if it's introduced it may be confusing why it's being
used some places but not others. Maybe the bounds in the debug virtual check
should just be adjusted so we don't need __pa_symbol along with a nice fat
comment explaining why.
>
> Thanks.
>
Thanks,
Laura
^ permalink raw reply
* Re: [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Laura Abbott @ 2016-11-14 18:41 UTC (permalink / raw)
To: Catalin Marinas, Mark Rutland
Cc: Ard Biesheuvel, x86, Will Deacon, linux-kernel, linux-mm,
Ingo Molnar, H. Peter Anvin, Joonsoo Kim, Thomas Gleixner,
Andrew Morton, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20161114181937.GG3096@e104818-lin.cambridge.arm.com>
On 11/14/2016 10:19 AM, Catalin Marinas wrote:
> On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
>> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
>>> On 11/02/2016 04:52 PM, Mark Rutland wrote:
>>>> On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
>>>>>
>>>>> __pa_symbol is technically the marco that should be used for kernel
>>>>> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
>>>>
>>>> Nit: s/marco/macro/
>>>>
>>>> I see there are some other uses of __pa() that look like they could/should be
>>>> __pa_symbol(), e.g. in mark_rodata_ro().
>>>>
>>>> I guess strictly speaking those need to be updated to? Or is there a reason
>>>> that we should not?
>>>
>>> If the concept of __pa_symbol is okay then yes I think all uses of __pa
>>> should eventually be converted for consistency and debugging.
>>
>> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
>> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
>> for consistency with other architectures.
>
> At a quick grep, it seems to only be used by mips and x86 and a single
> place in mm/memblock.c.
>
> Since we haven't seen any issues on arm/arm64 without this macro, can we
> not just continue to use __pa()?
Technically yes but if it's introduced it may be confusing why it's being
used some places but not others. Maybe the bounds in the debug virtual check
should just be adjusted so we don't need __pa_symbol along with a nice fat
comment explaining why.
>
> Thanks.
>
Thanks,
Laura
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Laura Abbott @ 2016-11-14 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114181937.GG3096@e104818-lin.cambridge.arm.com>
On 11/14/2016 10:19 AM, Catalin Marinas wrote:
> On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
>> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
>>> On 11/02/2016 04:52 PM, Mark Rutland wrote:
>>>> On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
>>>>>
>>>>> __pa_symbol is technically the marco that should be used for kernel
>>>>> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
>>>>
>>>> Nit: s/marco/macro/
>>>>
>>>> I see there are some other uses of __pa() that look like they could/should be
>>>> __pa_symbol(), e.g. in mark_rodata_ro().
>>>>
>>>> I guess strictly speaking those need to be updated to? Or is there a reason
>>>> that we should not?
>>>
>>> If the concept of __pa_symbol is okay then yes I think all uses of __pa
>>> should eventually be converted for consistency and debugging.
>>
>> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
>> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
>> for consistency with other architectures.
>
> At a quick grep, it seems to only be used by mips and x86 and a single
> place in mm/memblock.c.
>
> Since we haven't seen any issues on arm/arm64 without this macro, can we
> not just continue to use __pa()?
Technically yes but if it's introduced it may be confusing why it's being
used some places but not others. Maybe the bounds in the debug virtual check
should just be adjusted so we don't need __pa_symbol along with a nice fat
comment explaining why.
>
> Thanks.
>
Thanks,
Laura
^ permalink raw reply
* Re: [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Russell King - ARM Linux @ 2016-11-14 18:41 UTC (permalink / raw)
To: Steven Rostedt
Cc: Stephen Boyd, linux-kernel, linux-arm-kernel, Andrew Morton
In-Reply-To: <20161114133641.09b1abfb@gandalf.local.home>
On Mon, Nov 14, 2016 at 01:36:41PM -0500, Steven Rostedt wrote:
> On Tue, 18 Oct 2016 20:07:07 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Tue, 18 Oct 2016 16:42:00 -0700
> > Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > > In similar spirit to x86 and arm64 support, add a make_nop_arm()
> > > to replace calls to mcount with a nop in sections that aren't
> > > traced.
> > >
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Acked-by: Rabin Vincent <rabin@rab.in>
> > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >
> > I can take this if I can get an ack from the ARM maintainers.
>
> Any ARM maintainer want to ack this, or take it in their tree if they
> haven't already?
Assuming it's been tested:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.