Re: [PATCH v4 2/2] dt-bindings: pinctrl: qcom: Add SDM660 pinctrl binding
On Wed, Sep 26, 2018 at 6:26 PM Craig Tatlor wrote: > Add the binding for the TLMM pinctrl block found in the SDM660 platform. > > Signed-off-by: Craig Tatlor > --- > Changes from v3: >Updated for tile structure >change irq field This v3 applied with the ACKs. Yours, Linus Walleij
Re: [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration
On Wed 03-10-18 07:46:27, Anshuman Khandual wrote: > > > On 10/02/2018 06:09 PM, Michal Hocko wrote: > > On Tue 02-10-18 17:45:28, Anshuman Khandual wrote: > >> Architectures like arm64 have PUD level HugeTLB pages for certain configs > >> (1GB huge page is PUD based on ARM64_4K_PAGES base page size) that can be > >> enabled for migration. It can be achieved through checking for PUD_SHIFT > >> order based HugeTLB pages during migration. > > > > Well a long term problem with hugepage_migration_supported is that it is > > used in two different context 1) to bail out from the migration early > > because the arch doesn't support migration at all and 2) to use movable > > zone for hugetlb pages allocation. I am especially concerned about the > > later because the mere support for migration is not really good enough. > > Are you really able to find a different giga page during the runtime to > > move an existing giga page out of the movable zone? > > I pre-allocate them before trying to initiate the migration (soft offline > in my experiments). Hence it should come from the pre-allocated HugeTLB > pool instead from the buddy. I might be missing something here but do we > ever allocate HugeTLB on the go when trying to migrate ? IIUC it always > came from the pool (unless its something related to ovecommit/surplus). > Could you please kindly explain regarding how migration target HugeTLB > pages are allocated on the fly from movable zone. Hotplug comes to mind. You usually do not pre-allocate to cover full node going offline. And people would like to do that. Another example is CMA. You would really like to move pages out of the way. > But even if there are some chances of run time allocation failure from > movable zone (as in point 2) that should not block the very initiation > of migration itself. IIUC thats not the semantics for either THP or > normal pages. Why should it be different here. If the allocation fails > we should report and abort as always. Its the caller of migration taking > the chances. why should we prevent that. Yes I agree, hence the distinction between the arch support for migrateability and the criterion on the movable zone placement. > > > > So I guess we want to split this into two functions > > arch_hugepage_migration_supported and hugepage_movable. The later would > > So the set difference between arch_hugepage_migration_supported and > hugepage_movable still remains un-migratable ? Then what is the purpose > for arch_hugepage_migration_supported page size set in the first place. > Does it mean we allow the migration at the beginning and the abort later > when the page size does not fall within the subset for hugepage_movable. > Could you please kindly explain this in more detail. The purpose of arch_hugepage_migration_supported is to tell whether it makes any sense to even try to migration. The allocation placement is completely independent on this choice. The later just says whether it is feasible to place a hugepage to the zone movable. Sure regular 2MB pages do not guarantee movability as well because of the memory fragmentation. But allocating a 2MB is a completely different storage from 1G or even larger huge pages, isn't it? > > be a reasonably migrateable subset of the former. Without that this > > patch migth introduce subtle regressions when somebody relies on movable > > zone to be really movable. > PUD based HugeTLB pages were never migratable, then how can there be any > regression here ? That means that they haven't been allocated from the movable zone before. Which is going to change by this patch. > At present we even support PGD based HugeTLB pages for > migration. And that is already wrong but nobody probably cares because those are rarely used. > Wondering how PUD based ones are going to be any different. It is not different, PGD is dubious already. -- Michal Hocko SUSE Labs
Re: [PATCH] clocksource/drivers/fttmr010: fix invalid interrupt register access
On Wed, Oct 3, 2018 at 12:08 AM Tao Ren wrote: > 1) adding "is_aspeed" flag. "count_down" is kept because potentially > faraday-fttmr could also be configured as count_down timer (although I don't > see any reason to do so). > 2) renaming "count_down" to "is_aspeed". By doing this, we set > restriction that faraday-fttmr will always be upward. > What's your thought? Do you want me to include all the changes in this diff? My thought is go for (2) and do all changes in one patch :) Yours, Linus Walleij
Re: linux-next: occassional build errors
Hi Masahiro,
On Wed, 3 Oct 2018 13:31:54 +0900 Masahiro Yamada
wrote:
>
> On Wed, Oct 3, 2018 at 12:51 PM Stephen Rothwell
> wrote:
> >
> > I don't know if that has anything to changes in the kbuild system, but
> > since Tuesday, I have been getting random build errors that go away after
> > I remove the object directory and build again.
>
> I have no idea.
I did not expect a fast/simple answer :-)
> Is it fine if you use kbuild tree from the last week?
I did not see this in next-20180928 or before i.e. it has only happened
yesterday and today.
> I added 4 kbuild patches this week, but they look irrelevant.
Yeah, that was my feeling as well.
> > The latest example is this:
> >
> > include/linux/kconfig.h: file not recognized: file format not recognized
> > make[2]: *** [scripts/Makefile.build:492: crypto/crypto_user.o] Error 1
> > make[1]: *** [Makefile:1057: crypto] Error 2
> > make: *** [Makefile:152: sub-make] Error 2
> > Command exited with non-zero status 2
> >
> > It is always complaining about a .h file ...
> >
> > Makefile:152 is the MAKE lien below:
> >
> > # Invoke a second make in the output directory, passing relevant variables
> > sub-make:
> > $(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
> > -f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
> >
> > Makefile:1057 is the MAKE line below:
> >
> > PHONY += $(vmlinux-dirs)
> > $(vmlinux-dirs): prepare scripts
> > $(Q)$(MAKE) $(build)=$@ need-builtin=1
> >
> > scripts/Makefile.build:492 is the if_changed line below:
> >
> > $(multi-used-m): FORCE
> > $(call if_changed,link_multi-m)
> > @{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
> >$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
> > $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
> >
> > Not sure what else I can tell you.
>
> Does this happen only when building a module?
I don't know, sorry, I build with -s and -j80, so it is hard to tell
what it is currently up to.
> Can you provide a procedure
> to reproduce this?
Not really. Each day, I merge all the trees, but between each merge I
do 3 builds (arm, powerpc and x86_64) and of the 100+ builds, yesterday
2 failed and so far today 2 have failed. It is not even the same build
each time, or after the same merges.
The report above was from the arm build, a while later (a few merges
later) the x86_64 build failed - complaining about a different .h file.
--
Cheers,
Stephen Rothwell
pgpAdqCIXlgQA.pgp
Description: OpenPGP digital signature
Re: [PATCH 2/2] tty: wipe buffer if not echoing data
On 02/10/2018 19:17, Greg Kroah-Hartman wrote:
> From: Greg KH
>
> If we are not echoing the data to userspace, then perhaps it is a
> "secret" so we should wipe it once we are done with it.
Just to explain our test case for cryptsetup, where aszlig initially reported
it:
cryptsetup reads a passphrase from terminal, derives a candidate key for keyslot
decryption and immediately wipes the passphrase from memory, because it is
not needed anymore.
And here is the problem - the kernel keeps this passphrase in a tty buffer
memory
that is no longer available to userspace. It can be retrieved from memory dump
later, even after the crypt mapping is destroyed.
Almost all userspace tools working with passphrases through tty access have
the same problem here.
> This mirrors the logic that the audit code has.
>
> Reported-by: aszlig
> Tested-by: Milan Broz
> Tested-by: aszlig
> Cc: Willy Tarreau
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/tty/n_tty.c | 20 +---
...
> static int tty_copy_to_user(struct tty_struct *tty, void __user *to,
> size_t tail, size_t n)
> {
> struct n_tty_data *ldata = tty->disc_data;
> size_t size = N_TTY_BUF_SIZE - tail;
> - const void *from = read_buf_addr(ldata, tail);
> + void *from = read_buf_addr(ldata, tail);
> int uncopied;
>
> if (n > size) {
> tty_audit_add_data(tty, from, size);
> uncopied = copy_to_user(to, from, size);
> + zero_buffer(tty, from, size);
I think Linus mentioned in some previous mail that there should be
zero_buffer(tty, from, size - uncopied);
to avoid wiping of yet uncopied data.
I tested the unmodified version though...
> if (uncopied)
> return uncopied;
> to += size;
> @@ -171,7 +182,9 @@ static int tty_copy_to_user(struct tty_struct *tty, void
> __user *to,
> }
>
> tty_audit_add_data(tty, from, n);
> - return copy_to_user(to, from, n);
> + uncopied = copy_to_user(to, from, n);
> + zero_buffer(tty, from, n);
> + return uncopied;
> }
Milan
Re: [PATCH v6 0/3] Add a kernel parameter to change the padding size for KASLR
* Masayoshi Mizuma wrote: > This patch series are adding an kernel parameter to change > the padding size used for KASLR. It is useful for memory hotplug > capable system. User can adjust the padding size to use it. > > It is better if the padding size is calculated automatically, > however, ACPI SRAT is not available at the KASLR initialization > time. So, I add a message for user to tell the suitable padding > size. User can set it on next reboot. > > This patch series don't change the current default padding size. > > Change log from v5: > - Fix build error if CONFIG_RANDOMIZE_MEMORY is not defined. Please send a delta patch on top of tip:x86/boot with the get_rand_mem_physical_padding() fix, when doing that you'll see that I did some minor cleanups when applying the patches which your v6 series undoes. Thanks, Ingo
Re: [PATCH 1/3] x86/intel_rdt: Introduce utility to obtain CDP peer
On Wed, 26 Sep 2018, Reinette Chatre wrote:
> + * Return: 0 if a CDP peer was found, <0 on error or if no CDP peer exists.
> + * If a CDP peer was found, @r_cdp will point to the peer RDT
> resource
> + * and @d_cdp will point to the peer RDT domain.
> + */
> +static int __attribute__((unused)) rdt_cdp_peer_get(struct rdt_resource *r,
> + struct rdt_domain *d,
> + struct rdt_resource **r_cdp,
> + struct rdt_domain **d_cdp)
> +{
> + struct rdt_resource *_r_cdp = NULL;
> + struct rdt_domain *_d_cdp = NULL;
> + int ret = 0;
> +
> + switch (r->rid) {
> + case RDT_RESOURCE_L3DATA:
> + _r_cdp = &rdt_resources_all[RDT_RESOURCE_L3CODE];
> + break;
> + case RDT_RESOURCE_L3CODE:
> + _r_cdp = &rdt_resources_all[RDT_RESOURCE_L3DATA];
> + break;
> + case RDT_RESOURCE_L2DATA:
> + _r_cdp = &rdt_resources_all[RDT_RESOURCE_L2CODE];
> + break;
> + case RDT_RESOURCE_L2CODE:
> + _r_cdp = &rdt_resources_all[RDT_RESOURCE_L2DATA];
> + break;
> + default:
> + ret = -ENOENT;
> + goto out;
> + }
> +
> + /*
> + * When a new CPU comes online and CDP is enabled then the new
> + * RDT domains (if any) associated with both CDP RDT resources
> + * are added in the same CPU online routine while the
> + * rdtgroup_mutex is held. It should thus not happen for one
> + * RDT domain to exist and be associated with its RDT CDP
> + * resource but there is no RDT domain associated with the
> + * peer RDT CDP resource. Hence the WARN.
> + */
> + _d_cdp = rdt_find_domain(_r_cdp, d->id, NULL);
> + if (WARN_ON(!_d_cdp)) {
> + _r_cdp = NULL;
> + ret = -ENOENT;
While this should never happen, the return value is ambiguous. I'd rather
use EINVAL or such and propagate it further down at the call site.
Thanks,
tglx
[tip:x86/urgent] x86/cpu/amd: Remove unnecessary parentheses
Commit-ID: 88296bd42b4e9d24e138a68b337c235b5cac89a7
Gitweb: https://git.kernel.org/tip/88296bd42b4e9d24e138a68b337c235b5cac89a7
Author: Nathan Chancellor
AuthorDate: Tue, 2 Oct 2018 15:45:11 -0700
Committer: Ingo Molnar
CommitDate: Wed, 3 Oct 2018 08:27:47 +0200
x86/cpu/amd: Remove unnecessary parentheses
Clang warns when multiple pairs of parentheses are used for a single
conditional statement.
arch/x86/kernel/cpu/amd.c:925:14: warning: equality comparison with
extraneous parentheses [-Wparentheses-equality]
if ((c->x86 == 6)) {
~~~^~~~
arch/x86/kernel/cpu/amd.c:925:14: note: remove extraneous parentheses
around the comparison to silence this warning
if ((c->x86 == 6)) {
~ ^ ~
arch/x86/kernel/cpu/amd.c:925:14: note: use '=' to turn this equality
comparison into an assignment
if ((c->x86 == 6)) {
^~
=
1 warning generated.
Signed-off-by: Nathan Chancellor
Cc: Borislav Petkov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20181002224511.14929-1-natechancel...@gmail.com
Link: https://github.com/ClangBuiltLinux/linux/issues/187
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/cpu/amd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 22ab408177b2..eeea634bee0a 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -922,7 +922,7 @@ static void init_amd(struct cpuinfo_x86 *c)
static unsigned int amd_size_cache(struct cpuinfo_x86 *c, unsigned int size)
{
/* AMD errata T13 (order #21922) */
- if ((c->x86 == 6)) {
+ if (c->x86 == 6) {
/* Duron Rev A0 */
if (c->x86_model == 3 && c->x86_stepping == 0)
size = 64;
[tip:x86/urgent] x86/vdso: Only enable vDSO retpolines when enabled and supported
Commit-ID: 4f166564014aba65ad6f15b612f6711fd0f117ee
Gitweb: https://git.kernel.org/tip/4f166564014aba65ad6f15b612f6711fd0f117ee
Author: Andy Lutomirski
AuthorDate: Tue, 2 Oct 2018 21:26:50 -0700
Committer: Ingo Molnar
CommitDate: Wed, 3 Oct 2018 08:26:14 +0200
x86/vdso: Only enable vDSO retpolines when enabled and supported
When I fixed the vDSO build to use inline retpolines, I messed up
the Makefile logic and made it unconditional. It should have
depended on CONFIG_RETPOLINE and on the availability of compiler
support. This broke the build on some older compilers.
Reported-by: nikola.cipr...@linuxbox.cz
Signed-off-by: Andy Lutomirski
Cc: Borislav Petkov
Cc: David Woodhouse
Cc: Linus Torvalds
Cc: Matt Rickard
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: jason.vas.d...@gmail.com
Cc: sta...@vger.kernel.org
Fixes: 2e549b2ee0e3 ("x86/vdso: Fix vDSO build if a retpoline is emitted")
Link:
http://lkml.kernel.org/r/08a1f29f2c238dd1f493945e702a521f8a5aa3ae.1538540801.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/entry/vdso/Makefile | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index fa3f439f0a92..141d415a8c80 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -68,7 +68,13 @@ $(obj)/vdso-image-%.c: $(obj)/vdso%.so.dbg $(obj)/vdso%.so
$(obj)/vdso2c FORCE
CFL := $(PROFILING) -mcmodel=small -fPIC -O2 -fasynchronous-unwind-tables -m64
\
$(filter -g%,$(KBUILD_CFLAGS)) $(call cc-option, -fno-stack-protector) \
-fno-omit-frame-pointer -foptimize-sibling-calls \
- -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO $(RETPOLINE_VDSO_CFLAGS)
+ -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
+
+ifdef CONFIG_RETPOLINE
+ifneq ($(RETPOLINE_VDSO_CFLAGS),)
+ CFL += $(RETPOLINE_VDSO_CFLAGS)
+endif
+endif
$(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS)
$(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
@@ -138,7 +144,13 @@ KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector)
KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
KBUILD_CFLAGS_32 += -fno-omit-frame-pointer
KBUILD_CFLAGS_32 += -DDISABLE_BRANCH_PROFILING
-KBUILD_CFLAGS_32 += $(RETPOLINE_VDSO_CFLAGS)
+
+ifdef CONFIG_RETPOLINE
+ifneq ($(RETPOLINE_VDSO_CFLAGS),)
+ KBUILD_CFLAGS_32 += $(RETPOLINE_VDSO_CFLAGS)
+endif
+endif
+
$(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
$(obj)/vdso32.so.dbg: FORCE \
Re: [PATCH 2/2] clk: qcom: gcc: Add global clock controller driver for QCS404
Hi Stephen,
Thanks for the comments,
On 01-10-18, 10:19, Stephen Boyd wrote:
> Quoting Vinod Koul (2018-09-21 11:59:36)
> > From: Shefali Jain
> >
> > Add the clocks supported in global clock controller which clock the
> > peripherals like BLSPs, SDCC, USB, MDSS etc. Register all the clocks
> > to the clock framework for the clients to be able to request for them.
> >
> > Signed-off-by: Shefali Jain
> > Signed-off-by: Taniya Das
> > Co-developed-by: Taniya Das
> > Signed-off-by: Anu Ramanathan
> > [rebase and tidyup for upstream]
>
> Who did the tidying?
both of us :)
> > Signed-off-by: Bjorn Andersson
> > Signed-off-by: Vinod Koul
> > ---
> > - reg : shall contain base register location and length
> > diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> > index 064768699fe7..529d84cc7503 100644
> > --- a/drivers/clk/qcom/Kconfig
> > +++ b/drivers/clk/qcom/Kconfig
> > @@ -235,6 +235,14 @@ config MSM_GCC_8998
> > Say Y if you want to use peripheral devices such as UART, SPI,
> > i2c, USB, UFS, SD/eMMC, PCIe, etc.
> >
> > +config QCS_GCC_404
> > + tristate "QCS404 Global Clock Controller"
> > + depends on COMMON_CLK_QCOM
> > + help
> > +Support for the global clock controller on QCS404 devices.
> > +Say Y if you want to use peripheral devices such as UART, SPI, I2C,
> > +USB, SD/eMMC, PCIe, etc.
>
> It seems to include multimedia display clks and ethernet? Maybe include
> those too.
Sure will add
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Please don't include this.
OK will check if this is required, any reason for not including this?
> > +/* 930MHz configuration */
> > +static const struct alpha_pll_config gpll3_config = {
> > + .l = 48,
> > + .alpha = 0x0,
> > + .alpha_en_mask = BIT(24),
> > + .post_div_mask = 0xf << 8,
> > + .post_div_val = 0x1 << 8,
> > + .vco_mask = 0x3 << 20,
> > + .main_output_mask = 0x1,
> > + .config_ctl_val = 0x4001055b,
> > +};
> > +
> > +static struct pll_vco gpll3_vco[] = {
>
> const?
sure
> > +static struct clk_branch gcc_pwm1_xo512_clk = {
> > + .halt_reg = 0x49004,
> > + .halt_check = BRANCH_HALT,
> > + .clkr = {
> > + .enable_reg = 0x49004,
> > + .enable_mask = BIT(0),
> > + .hw.init = &(struct clk_init_data){
> > + .name = "gcc_pwm1_xo512_clk",
> > + .ops = &clk_branch2_ops,
>
> Do these pwm clks have a parent clk of the XO?
Yes they do
> > + [GCC_USB_HS_PHY_CFG_AHB_CLK] = &gcc_usb_hs_phy_cfg_ahb_clk.clkr,
> > + [GCC_USB_HS_SYSTEM_CLK] = &gcc_usb_hs_system_clk.clkr,
> > + [GFX3D_CLK_SRC] = &gfx3d_clk_src.clkr,
> > + [GP1_CLK_SRC] = &gp1_clk_src.clkr,
>
> Why are some of these missing GCC_ prefix?
will add..
> > +static int gcc_qcs404_probe(struct platform_device *pdev)
> > +{
> > + struct regmap *regmap;
> > + int ret;
> > +
> > + ret = qcom_cc_register_board_clk(&pdev->dev,
> > +"xo_board", "cxo", 1920);
>
> You shouldn't need to do this. This function is for transitioning DT
> that doesn't have the board clk in DT to something the driver wants to
> use, in this case "cxo". So you can either register a fixed factor 1/1
> clk to do the translation between board and cxo names, or use xo_board
> as the parent of things that can take crystal.
Okay will modify this. If I go about using xo_board as parent, I would
need to register that right? FWIW I see the same thing done in gcc-msm8916
>
> > + if (ret)
> > + return ret;
> > +
> > + regmap = qcom_cc_map(pdev, &gcc_qcs404_desc);
> > + if (IS_ERR(regmap))
> > + return PTR_ERR(regmap);
> > +
> > + clk_alpha_pll_configure(&gpll3_out_main, regmap, &gpll3_config);
> > + clk_set_rate(apss_ahb_clk_src.clkr.hw.clk, 1920);
>
> use assigned clock rates from DT please.
ok
> > + clk_prepare_enable(apss_ahb_clk_src.clkr.hw.clk);
> > + clk_prepare_enable(gpll0_ao_out_main.clkr.hw.clk);
>
> And these should be marked as critical clocks.
Okay and how do we go about doing that?
> > +#define GCC_USB2A_PHY_SLEEP_CLK89
> > +#define GCC_USB30_MASTER_CLK 90
> > +#define GCC_USB30_MOCK_UTMI_CLK91
> > +#define gcc_usb30_sleep_clk92
> > +#define gcc_usb3_phy_aux_clk 93
> > +#define gcc_usb3_phy_pipe_clk 94
> > +#define gcc_usb_hs_phy_cfg_ahb_clk 95
> > +#define gcc_usb_hs_system_clk 96
> > +#define gfx3d_clk_src 97
> > +#define gp1_clk_src98
> > +#define gp2_clk_src99
> > +#define gp3
Re: Setting monotonic time?
On Wed, 3 Oct 2018, Thomas Gleixner wrote: > On Wed, 3 Oct 2018, Eric W. Biederman wrote: > > Direct access to hardware/drivers and not through an abstraction like > > the vfs (an abstraction over block devices) can legitimately be handled > > by hotplug events. I unplug one keyboard I plug in another. > > > > I don't know if the input layer is more of a general abstraction > > or more of a hardware device. I have not dug into it but my guess > > is abstraction from what I have heard. > > > > The scary difficulty here is if after restart input is reporting times > > in CLOCK_MONOTONIC and the applications in the namespace are talking > > about times in CLOCK_MONOTONIC_SYNC. Then there is an issue. As even > > with a fixed offset the times don't match up. > > > > So a time namespace absolutely needs to do is figure out how to deal > > with all of the kernel interfaces reporting times and figure out how to > > report them in the current time namespace. > > So you want to talk to Arnd who is leading the y2038 effort. He knowns how > many and which interfaces are involved aside of the obvious core timer > ones. It's quite an amount and the problem is that you really need to do > that at the interface level, because many of those time stamps are taken in > contexts which are completely oblivious of name spaces. Ditto for timeouts > and similar things which are handed in through these interfaces. Plus you have to make sure, that any new interface will have that treatment. For y2038 that's easy as we just require to use timespec64 for new ones. For your problem that's not so trivial. Thanks, tglx
Re: Setting monotonic time?
Thomas Gleixner writes: > On Wed, 3 Oct 2018, Eric W. Biederman wrote: >> Direct access to hardware/drivers and not through an abstraction like >> the vfs (an abstraction over block devices) can legitimately be handled >> by hotplug events. I unplug one keyboard I plug in another. >> >> I don't know if the input layer is more of a general abstraction >> or more of a hardware device. I have not dug into it but my guess >> is abstraction from what I have heard. >> >> The scary difficulty here is if after restart input is reporting times >> in CLOCK_MONOTONIC and the applications in the namespace are talking >> about times in CLOCK_MONOTONIC_SYNC. Then there is an issue. As even >> with a fixed offset the times don't match up. >> >> So a time namespace absolutely needs to do is figure out how to deal >> with all of the kernel interfaces reporting times and figure out how to >> report them in the current time namespace. > > So you want to talk to Arnd who is leading the y2038 effort. He knowns how > many and which interfaces are involved aside of the obvious core timer > ones. It's quite an amount and the problem is that you really need to do > that at the interface level, because many of those time stamps are taken in > contexts which are completely oblivious of name spaces. Ditto for timeouts > and similar things which are handed in through these interfaces. Yep. That sounds right. Eric
Re: [PATCH] perf/x86/intel: Add counter freezing quirk for Goldmont
On Tue, 2 Oct 2018, kan.li...@linux.intel.com wrote:
> +static bool intel_atom_v4_counter_freezing_broken(int cpu)
> {
> u32 rev = UINT_MAX; /* default to broken for unknown stepping */
>
> - switch (cpu_data(cpu).x86_stepping) {
> - case 1:
> - rev = 0x28;
> + switch (cpu_data(cpu).x86_model) {
> + case INTEL_FAM6_ATOM_GOLDMONT:
> + switch (cpu_data(cpu).x86_stepping) {
> + case 2:
> + rev = 0xe;
> + break;
> + case 9:
> + rev = 0x2e;
> + break;
> + case 10:
> + rev = 0x8;
> + break;
> + }
> break;
> - case 8:
> - rev = 0x6;
> +
> + case INTEL_FAM6_ATOM_GOLDMONT_X:
> + switch (cpu_data(cpu).x86_stepping) {
> + case 1:
> + rev = 0x1a;
> + break;
> + }
> break;
> +
> + case INTEL_FAM6_ATOM_GOLDMONT_PLUS:
> + switch (cpu_data(cpu).x86_stepping) {
> + case 1:
> + rev = 0x28;
> + break;
> + case 8:
> + rev = 0x6;
> + break;
> + }
> }
>
> return (cpu_data(cpu).microcode < rev);
There is another variant of model/stepping micro code verification code in
intel_snb_pebs_broken(). Can we please make this table based and use a
common function? That's certainly not the last quirk we're going to have.
We already have a table based variant of ucode checking in
bad_spectre_microcode(). It's trivial enough to generalize that.
Thanks,
tglx
Re: [RFC v2 v2 1/1] ns: add binfmt_misc to the mount namespace
Laurent Vivier writes:
> This patch allows to have a different binftm_misc configuration
> in each container we mount binfmt_misc filesystem with mount namespace
> enabled.
>
> A container started without the CLONE_NEWNS will use the host binfmt_misc
> configuration, otherwise the container starts with an empty binfmt_misc
> interpreters list.
>
> For instance, using "unshare" we can start a chroot of an another
> architecture and configure the binfmt_misc interpreted without being root
> to run the binaries in this chroot.
A couple of things.
As has already been mentioned on your previous version anything that
comes through the filesystem interface needs to lookup up the local
binfmt context not through current but through file->f_dentry->d_sb.
AKA the superblock of the mounted filesystem.
As you have this coded any time a mount namespace is unshared you get a
new binfmt context. That has a very reasonable chance of breaking
existing userspace.
A mount of binfmt_misc today from within a user namespace is not allowed
which is why I have figured that will be a nice place to trigger
creating a new binfmt context.
It is fundamentally necessary to be able to get a pointer to the binfmt
context from current. Either stored in an existing namespace or
stored in nsproxy. Anything else will risk breaking backwards
compatibility with existing user space for no good reason.
What is fundamentally being changed is the behavior of exec.
Changing the behavior of exec needs to be carefully contained or we risk
confusing privileged applications.
I believe your last email to James Bottomley detailed a very strong use
case for this functionality.
As the key gains over the existing kernel is unprivileged use. As it is
the behavior of exec that is changing. You definitely need a user
namespace involved.
So I think the simplest would be to hang the binfmt context off of a
user namespace. But I am open to other ideas.
My primary concern is that we keep the cognitive and the maintenance
burden as small as is reasonably possible so that the costs don't out
weigh the benefit.
Eric
> Signed-off-by: Laurent Vivier
> ---
> fs/binfmt_misc.c | 50 +---
> fs/mount.h | 8
> fs/namespace.c | 6 ++
> 3 files changed, 40 insertions(+), 24 deletions(-)
>
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index aa4a7a23ff99..ecb14776c759 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include "internal.h"
>
> @@ -38,9 +39,6 @@ enum {
> VERBOSE_STATUS = 1 /* make it zero to save 400 bytes kernel memory */
> };
>
> -static LIST_HEAD(entries);
> -static int enabled = 1;
> -
> enum {Enabled, Magic};
> #define MISC_FMT_PRESERVE_ARGV0 (1 << 31)
> #define MISC_FMT_OPEN_BINARY (1 << 30)
> @@ -60,10 +58,7 @@ typedef struct {
> struct file *interp_file;
> } Node;
>
> -static DEFINE_RWLOCK(entries_lock);
> static struct file_system_type bm_fs_type;
> -static struct vfsmount *bm_mnt;
> -static int entry_count;
>
> /*
> * Max length of the register string. Determined by:
> @@ -91,7 +86,7 @@ static Node *check_file(struct linux_binprm *bprm)
> struct list_head *l;
>
> /* Walk all the registered handlers. */
> - list_for_each(l, &entries) {
> + list_for_each(l, &binfmt_ns(entries)) {
> Node *e = list_entry(l, Node, list);
> char *s;
> int j;
> @@ -135,15 +130,15 @@ static int load_misc_binary(struct linux_binprm *bprm)
> int fd_binary = -1;
>
> retval = -ENOEXEC;
> - if (!enabled)
> + if (!binfmt_ns(enabled))
> return retval;
>
> /* to keep locking time low, we copy the interpreter string */
> - read_lock(&entries_lock);
> + read_lock(&binfmt_ns(entries_lock));
> fmt = check_file(bprm);
> if (fmt)
> dget(fmt->dentry);
> - read_unlock(&entries_lock);
> + read_unlock(&binfmt_ns(entries_lock));
> if (!fmt)
> return retval;
>
> @@ -613,15 +608,15 @@ static void kill_node(Node *e)
> {
> struct dentry *dentry;
>
> - write_lock(&entries_lock);
> + write_lock(&binfmt_ns(entries_lock));
> list_del_init(&e->list);
> - write_unlock(&entries_lock);
> + write_unlock(&binfmt_ns(entries_lock));
>
> dentry = e->dentry;
> drop_nlink(d_inode(dentry));
> d_drop(dentry);
> dput(dentry);
> - simple_release_fs(&bm_mnt, &entry_count);
> + simple_release_fs(&binfmt_ns(bm_mnt), &binfmt_ns(entry_count));
> }
>
> /* / */
> @@ -716,7 +711,8 @@ static ssize_t bm_register_write(struct file *file, const
> char __user *buffer,
> if (!inode)
> goto out2;
>
> - err = simple_pin_fs(&bm_fs_type, &bm_mnt, &entry_count);
> + err = simple_pin_fs(&bm_fs_type, &binfmt_ns(bm_mnt),
> + &binfmt_ns(entry_
Re: [PATCH 15/16] apparmor: Replace spin_is_locked() with lockdep
On 10/02/2018 10:39 PM, Lance Roy wrote:
> lockdep_assert_held() is better suited to checking locking requirements,
> since it won't get confused when someone else holds the lock. This is
> also a step towards possibly removing spin_is_locked().
>
> Signed-off-by: Lance Roy
> Cc: John Johansen
> Cc: James Morris
> Cc: "Serge E. Hallyn"
> Cc:
Acked-by: John Johansen
> ---
> security/apparmor/file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index 4285943f7260..d0afed9ebd0e 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -496,7 +496,7 @@ static void update_file_ctx(struct aa_file_ctx *fctx,
> struct aa_label *label,
> /* update caching of label on file_ctx */
> spin_lock(&fctx->lock);
> old = rcu_dereference_protected(fctx->label,
> - spin_is_locked(&fctx->lock));
> + lockdep_is_held(&fctx->lock));
> l = aa_label_merge(old, label, GFP_ATOMIC);
> if (l) {
> if (l != old) {
>
[PATCH 01/16] x86/PCI: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Bjorn Helgaas
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc:
Cc:
---
arch/x86/pci/i386.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index ed4ac215305d..24bb58a007de 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -59,7 +59,7 @@ static struct pcibios_fwaddrmap
*pcibios_fwaddrmap_lookup(struct pci_dev *dev)
{
struct pcibios_fwaddrmap *map;
- WARN_ON_SMP(!spin_is_locked(&pcibios_fwaddrmap_lock));
+ lockdep_assert_held(&pcibios_fwaddrmap_lock);
list_for_each_entry(map, &pcibios_fwaddrmappings, list)
if (map->dev == dev)
--
2.19.0
[PATCH 10/16] userfaultfd: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements, since it won't get confused when someone else holds the lock. This is also a step towards possibly removing spin_is_locked(). Signed-off-by: Lance Roy Cc: Alexander Viro Cc: --- fs/userfaultfd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index bfa0ec69f924..a20244ff0027 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -926,7 +926,7 @@ static inline struct userfaultfd_wait_queue *find_userfault_in( wait_queue_entry_t *wq; struct userfaultfd_wait_queue *uwq; - VM_BUG_ON(!spin_is_locked(&wqh->lock)); + lockdep_assert_held(&wqh->lock); uwq = NULL; if (!waitqueue_active(wqh)) -- 2.19.0
Re: [PATCH 3/4] infiniband/mm: convert to the new put_user_page() call
On 10/1/18 7:35 AM, Dennis Dalessandro wrote: > On 9/28/2018 11:12 PM, John Hubbard wrote: >> On 9/28/18 8:39 AM, Jason Gunthorpe wrote: >>> On Thu, Sep 27, 2018 at 10:39:47PM -0700, john.hubb...@gmail.com wrote: From: John Hubbard >> [...] diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c index a41792dbae1f..9430d697cb9f 100644 +++ b/drivers/infiniband/core/umem.c @@ -60,7 +60,7 @@ static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem, int d page = sg_page(sg); if (!PageDirty(page) && umem->writable && dirty) set_page_dirty_lock(page); - put_page(page); + put_user_page(page); >>> >>> Would it make sense to have a release/put_user_pages_dirtied to absorb >>> the set_page_dity pattern too? I notice in this patch there is some >>> variety here, I wonder what is the right way? >>> >>> Also, I'm told this code here is a big performance bottleneck when the >>> number of pages becomes very long (think >> GB of memory), so having a >>> future path to use some kind of batching/threading sound great. >>> >> >> Yes. And you asked for this the first time, too. Consistent! :) Sorry for >> being slow to pick it up. It looks like there are several patterns, and >> we have to support both set_page_dirty() and set_page_dirty_lock(). So >> the best combination looks to be adding a few variations of >> release_user_pages*(), but leaving put_user_page() alone, because it's >> the "do it yourself" basic one. Scatter-gather will be stuck with that. >> >> Here's a differential patch with that, that shows a nice little cleanup in >> a couple of IB places, and as you point out, it also provides the hooks for >> performance upgrades (via batching) in the future. >> >> Does this API look about right? > > I'm on board with that and the changes to hfi1 and qib. > > Reviewed-by: Dennis Dalessandro Hi Dennis, thanks for the review! I'll add those new routines in and send out a v2 soon, now that it appears, from the recent discussion, that this aspect of the approach is still viable. thanks, -- John Hubbard NVIDIA
Using lockdep instead of spin_is_locked()
One of the main uses of spin_is_locked() is to require that a lock is held when a function is called, for debugging, but lockdep_assert_held() is better for this purpose since it won't make a mistake when someone else is holding the lock. This patch series replaces all of this kind of use of spin_is_locked() with calls to lockdep_assert_held(). An ulterior motive is to reduce the number of uses of spin_is_locked() from the kernel, to work towards possibly eliminating it. Thanks, Lance arch/x86/pci/i386.c | 2 +- drivers/hv/hv_balloon.c | 2 +- drivers/misc/sgi-xp/xpc_channel.c| 6 +++--- drivers/misc/sgi-xp/xpc_sn2.c| 2 +- drivers/misc/sgi-xp/xpc_uv.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +-- drivers/net/ethernet/intel/igbvf/mbx.c | 4 ++-- drivers/net/ethernet/sfc/efx.c | 2 +- drivers/net/ethernet/smsc/smsc911x.h | 2 +- drivers/net/wireless/zydas/zd1211rw/zd_mac.c | 2 +- drivers/scsi/snic/snic_scsi.c| 4 ++-- fs/userfaultfd.c | 2 +- kernel/futex.c | 4 ++-- kernel/locking/mutex-debug.c | 4 ++-- mm/khugepaged.c | 4 ++-- mm/swap.c| 3 +-- net/netfilter/ipset/ip_set_hash_gen.h| 2 +- security/apparmor/file.c | 2 +- virt/kvm/arm/vgic/vgic.c | 12 ++-- 19 files changed, 31 insertions(+), 33 deletions(-)
[PATCH 08/16] wireless: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Daniel Drake
Cc: Ulrich Kunitz
Cc: Kalle Valo
Cc: "David S. Miller"
Cc:
Cc:
---
drivers/net/wireless/zydas/zd1211rw/zd_mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
index 1f6d9f357e57..9ccd780695f0 100644
--- a/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zydas/zd1211rw/zd_mac.c
@@ -235,7 +235,7 @@ void zd_mac_clear(struct zd_mac *mac)
{
flush_workqueue(zd_workqueue);
zd_chip_clear(&mac->chip);
- ZD_ASSERT(!spin_is_locked(&mac->lock));
+ lockdep_assert_held(&mac->lock);
ZD_MEMCLEAR(mac, sizeof(struct zd_mac));
}
--
2.19.0
[PATCH 14/16] netfilter: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements, since it won't get confused when someone else holds the lock. This is also a step towards possibly removing spin_is_locked(). Signed-off-by: Lance Roy Cc: Pablo Neira Ayuso Cc: Jozsef Kadlecsik Cc: Florian Westphal Cc: "David S. Miller" Cc: Cc: Cc: --- net/netfilter/ipset/ip_set_hash_gen.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/netfilter/ipset/ip_set_hash_gen.h b/net/netfilter/ipset/ip_set_hash_gen.h index 8a33dac4e805..e287da68d5fa 100644 --- a/net/netfilter/ipset/ip_set_hash_gen.h +++ b/net/netfilter/ipset/ip_set_hash_gen.h @@ -15,7 +15,7 @@ #define __ipset_dereference_protected(p, c)rcu_dereference_protected(p, c) #define ipset_dereference_protected(p, set) \ - __ipset_dereference_protected(p, spin_is_locked(&(set)->lock)) + __ipset_dereference_protected(p, lockdep_is_held(&(set)->lock)) #define rcu_dereference_bh_nfnl(p) rcu_dereference_bh_check(p, 1) -- 2.19.0
[PATCH 04/16] i40e: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Jeff Kirsher
Cc: "David S. Miller"
Cc: intel-wired-...@lists.osuosl.org
Cc:
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index ac685ad4d877..8ce3471723d3 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -1489,8 +1489,7 @@ int i40e_del_mac_filter(struct i40e_vsi *vsi, const u8
*macaddr)
bool found = false;
int bkt;
- WARN(!spin_is_locked(&vsi->mac_filter_hash_lock),
-"Missing mac_filter_hash_lock\n");
+ lockdep_assert_held(&vsi->mac_filter_hash_lock);
hash_for_each_safe(vsi->mac_filter_hash, bkt, h, f, hlist) {
if (ether_addr_equal(macaddr, f->macaddr)) {
__i40e_del_filter(vsi, f);
--
2.19.0
Re: [PATCH] regulator/mfd: fix pointer-to-int cast
Hello Arnd,
On Tue, Oct 02, 2018 at 11:07:32PM +0200, Arnd Bergmann wrote:
> gcc points out that a pointer is longer than an int on 64-bit
> architectures, and that casting between the two may be dangerous:
>
> drivers/mfd/rohm-bd718x7.c: In function 'bd718xx_i2c_probe':
> drivers/mfd/rohm-bd718x7.c:101:23: error: cast from pointer to integer of
> different size [-Werror=pointer-to-int-cast]
>
> In this driver it is correct, we just need the right kind of cast
> to avoid the warning.
>
> Fixes: 494edd266b94 ("regulator/mfd: Support ROHM BD71847 power management
> IC")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/mfd/rohm-bd718x7.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/rohm-bd718x7.c b/drivers/mfd/rohm-bd718x7.c
> index 161c8aac6d86..e66d59190a82 100644
> --- a/drivers/mfd/rohm-bd718x7.c
> +++ b/drivers/mfd/rohm-bd718x7.c
> @@ -98,7 +98,7 @@ static int bd718xx_i2c_probe(struct i2c_client *i2c,
> return -ENOMEM;
>
> bd718xx->chip_irq = i2c->irq;
> - bd718xx->chip_type = (unsigned int)
> + bd718xx->chip_type = (uintptr_t)
> of_device_get_match_data(&i2c->dev);
> bd718xx->dev = &i2c->dev;
> dev_set_drvdata(&i2c->dev, bd718xx);
Big thanks for this activity =) I also got heads up mail from linux-next
so I also did a patch fixing this. I think Mark alrady applied that
patch to his tree.
(https://lore.kernel.org/lkml/20181002145901.899d41121...@debutante.sirena.org.uk/)
Br,
Matti Vaittinen
[PATCH 03/16] sgi-xp: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Cliff Whickman
Cc: Robin Holt
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
drivers/misc/sgi-xp/xpc_channel.c | 6 +++---
drivers/misc/sgi-xp/xpc_sn2.c | 2 +-
drivers/misc/sgi-xp/xpc_uv.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/sgi-xp/xpc_channel.c
b/drivers/misc/sgi-xp/xpc_channel.c
index 05a890ce2ab8..8e6607fc8a67 100644
--- a/drivers/misc/sgi-xp/xpc_channel.c
+++ b/drivers/misc/sgi-xp/xpc_channel.c
@@ -28,7 +28,7 @@ xpc_process_connect(struct xpc_channel *ch, unsigned long
*irq_flags)
{
enum xp_retval ret;
- DBUG_ON(!spin_is_locked(&ch->lock));
+ lockdep_assert_held(&ch->lock);
if (!(ch->flags & XPC_C_OPENREQUEST) ||
!(ch->flags & XPC_C_ROPENREQUEST)) {
@@ -82,7 +82,7 @@ xpc_process_disconnect(struct xpc_channel *ch, unsigned long
*irq_flags)
struct xpc_partition *part = &xpc_partitions[ch->partid];
u32 channel_was_connected = (ch->flags & XPC_C_WASCONNECTED);
- DBUG_ON(!spin_is_locked(&ch->lock));
+ lockdep_assert_held(&ch->lock);
if (!(ch->flags & XPC_C_DISCONNECTING))
return;
@@ -755,7 +755,7 @@ xpc_disconnect_channel(const int line, struct xpc_channel
*ch,
{
u32 channel_was_connected = (ch->flags & XPC_C_CONNECTED);
- DBUG_ON(!spin_is_locked(&ch->lock));
+ lockdep_assert_held(&ch->lock);
if (ch->flags & (XPC_C_DISCONNECTING | XPC_C_DISCONNECTED))
return;
diff --git a/drivers/misc/sgi-xp/xpc_sn2.c b/drivers/misc/sgi-xp/xpc_sn2.c
index 5a12d2a54049..0ae69b9390ce 100644
--- a/drivers/misc/sgi-xp/xpc_sn2.c
+++ b/drivers/misc/sgi-xp/xpc_sn2.c
@@ -1671,7 +1671,7 @@ xpc_teardown_msg_structures_sn2(struct xpc_channel *ch)
{
struct xpc_channel_sn2 *ch_sn2 = &ch->sn.sn2;
- DBUG_ON(!spin_is_locked(&ch->lock));
+ lockdep_assert_held(&ch->lock);
ch_sn2->remote_msgqueue_pa = 0;
diff --git a/drivers/misc/sgi-xp/xpc_uv.c b/drivers/misc/sgi-xp/xpc_uv.c
index 340b44d9e8cf..0441abe87880 100644
--- a/drivers/misc/sgi-xp/xpc_uv.c
+++ b/drivers/misc/sgi-xp/xpc_uv.c
@@ -1183,7 +1183,7 @@ xpc_teardown_msg_structures_uv(struct xpc_channel *ch)
{
struct xpc_channel_uv *ch_uv = &ch->sn.uv;
- DBUG_ON(!spin_is_locked(&ch->lock));
+ lockdep_assert_held(&ch->lock);
kfree(ch_uv->cached_notify_gru_mq_desc);
ch_uv->cached_notify_gru_mq_desc = NULL;
--
2.19.0
[PATCH 12/16] locking/mutex: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
---
kernel/locking/mutex-debug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
index 9aa713629387..771d4ca96dda 100644
--- a/kernel/locking/mutex-debug.c
+++ b/kernel/locking/mutex-debug.c
@@ -36,7 +36,7 @@ void debug_mutex_lock_common(struct mutex *lock, struct
mutex_waiter *waiter)
void debug_mutex_wake_waiter(struct mutex *lock, struct mutex_waiter *waiter)
{
- SMP_DEBUG_LOCKS_WARN_ON(!spin_is_locked(&lock->wait_lock));
+ lockdep_assert_held(&lock->wait_lock);
DEBUG_LOCKS_WARN_ON(list_empty(&lock->wait_list));
DEBUG_LOCKS_WARN_ON(waiter->magic != waiter);
DEBUG_LOCKS_WARN_ON(list_empty(&waiter->list));
@@ -51,7 +51,7 @@ void debug_mutex_free_waiter(struct mutex_waiter *waiter)
void debug_mutex_add_waiter(struct mutex *lock, struct mutex_waiter *waiter,
struct task_struct *task)
{
- SMP_DEBUG_LOCKS_WARN_ON(!spin_is_locked(&lock->wait_lock));
+ lockdep_assert_held(&lock->wait_lock);
/* Mark the current thread as blocked on the lock: */
task->blocked_on = waiter;
--
2.19.0
[PATCH 07/16] smsc: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Steve Glendinning
Cc: "David S. Miller"
Cc:
---
drivers/net/ethernet/smsc/smsc911x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.h
b/drivers/net/ethernet/smsc/smsc911x.h
index 8d75508acd2b..51b2fc1a395f 100644
--- a/drivers/net/ethernet/smsc/smsc911x.h
+++ b/drivers/net/ethernet/smsc/smsc911x.h
@@ -67,7 +67,7 @@
#ifdef CONFIG_DEBUG_SPINLOCK
#define SMSC_ASSERT_MAC_LOCK(pdata) \
- WARN_ON_SMP(!spin_is_locked(&pdata->mac_lock))
+ lockdep_assert_held(&pdata->mac_lock)
#else
#define SMSC_ASSERT_MAC_LOCK(pdata) do {} while (0)
#endif /* CONFIG_DEBUG_SPINLOCK */
--
2.19.0
[PATCH 02/16] hv_balloon: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements, since it won't get confused when someone else holds the lock. This is also a step towards possibly removing spin_is_locked(). Signed-off-by: Lance Roy Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: --- drivers/hv/hv_balloon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index b1b788082793..41631512ae97 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -689,7 +689,7 @@ static void hv_page_online_one(struct hv_hotadd_state *has, struct page *pg) __online_page_increment_counters(pg); __online_page_free(pg); - WARN_ON_ONCE(!spin_is_locked(&dm_device.ha_lock)); + lockdep_assert_held(&dm_device.ha_lock); dm_device.num_pages_onlined++; } -- 2.19.0
[PATCH 11/16] futex: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Darren Hart
---
kernel/futex.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 11fc3bb456d6..3e2de8fc1891 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1365,9 +1365,9 @@ static void __unqueue_futex(struct futex_q *q)
{
struct futex_hash_bucket *hb;
- if (WARN_ON_SMP(!q->lock_ptr || !spin_is_locked(q->lock_ptr))
- || WARN_ON(plist_node_empty(&q->list)))
+ if (WARN_ON_SMP(!q->lock_ptr) || WARN_ON(plist_node_empty(&q->list)))
return;
+ lockdep_assert_held(q->lock_ptr);
hb = container_of(q->lock_ptr, struct futex_hash_bucket, lock);
plist_del(&q->list, &hb->chain);
--
2.19.0
[PATCH 13/16] mm: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Andrew Morton
Cc: "Kirill A. Shutemov"
Cc: Yang Shi
Cc: Matthew Wilcox
Cc: Mel Gorman
Cc: Vlastimil Babka
Cc: Jan Kara
Cc: Shakeel Butt
Cc:
---
mm/khugepaged.c | 4 ++--
mm/swap.c | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index a31d740e6cd1..80f12467ccb3 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1225,7 +1225,7 @@ static void collect_mm_slot(struct mm_slot *mm_slot)
{
struct mm_struct *mm = mm_slot->mm;
- VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(&khugepaged_mm_lock));
+ lockdep_assert_held(&khugepaged_mm_lock);
if (khugepaged_test_exit(mm)) {
/* free mm_slot */
@@ -1665,7 +1665,7 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int
pages,
int progress = 0;
VM_BUG_ON(!pages);
- VM_BUG_ON(NR_CPUS != 1 && !spin_is_locked(&khugepaged_mm_lock));
+ lockdep_assert_held(&khugepaged_mm_lock);
if (khugepaged_scan.mm_slot)
mm_slot = khugepaged_scan.mm_slot;
diff --git a/mm/swap.c b/mm/swap.c
index 26fc9b5f1b6c..c89eb442c0bf 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -824,8 +824,7 @@ void lru_add_page_tail(struct page *page, struct page
*page_tail,
VM_BUG_ON_PAGE(!PageHead(page), page);
VM_BUG_ON_PAGE(PageCompound(page_tail), page);
VM_BUG_ON_PAGE(PageLRU(page_tail), page);
- VM_BUG_ON(NR_CPUS != 1 &&
- !spin_is_locked(&lruvec_pgdat(lruvec)->lru_lock));
+ lockdep_assert_held(&lruvec_pgdat(lruvec)->lru_lock);
if (!list)
SetPageLRU(page_tail);
--
2.19.0
[PATCH 15/16] apparmor: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements,
since it won't get confused when someone else holds the lock. This is
also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: John Johansen
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc:
---
security/apparmor/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index 4285943f7260..d0afed9ebd0e 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -496,7 +496,7 @@ static void update_file_ctx(struct aa_file_ctx *fctx,
struct aa_label *label,
/* update caching of label on file_ctx */
spin_lock(&fctx->lock);
old = rcu_dereference_protected(fctx->label,
- spin_is_locked(&fctx->lock));
+ lockdep_is_held(&fctx->lock));
l = aa_label_merge(old, label, GFP_ATOMIC);
if (l) {
if (l != old) {
--
2.19.0
linux-next: manual merge of the devicetree tree with the c6x tree
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
arch/c6x/kernel/setup.c
between commit:
31b02fe54206 ("c6x: switch to NO_BOOTMEM")
from the c6x tree and commit:
be7cd2df1d22 ("c6x: use common built-in dtb support")
from the devicetree tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/c6x/kernel/setup.c
index cc74cb9d349b,05d96a9541b5..
--- a/arch/c6x/kernel/setup.c
+++ b/arch/c6x/kernel/setup.c
@@@ -352,7 -348,17 +347,7 @@@ void __init setup_arch(char **cmdline_p
init_mm.end_data = memory_start;
init_mm.brk= memory_start;
- unflatten_device_tree();
- /*
- * Give all the memory to the bootmap allocator, tell it to put the
- * boot mem_map at the start of memory
- */
- bootmap_size = init_bootmem_node(NODE_DATA(0),
- memory_start >> PAGE_SHIFT,
- PAGE_OFFSET >> PAGE_SHIFT,
- memory_end >> PAGE_SHIFT);
- memblock_reserve(memory_start, bootmap_size);
-
+ unflatten_and_copy_device_tree();
c6x_cache_init();
pgpO5uTGSTKGX.pgp
Description: OpenPGP digital signature
Re: Setting monotonic time?
On Wed, 3 Oct 2018, Eric W. Biederman wrote: > Direct access to hardware/drivers and not through an abstraction like > the vfs (an abstraction over block devices) can legitimately be handled > by hotplug events. I unplug one keyboard I plug in another. > > I don't know if the input layer is more of a general abstraction > or more of a hardware device. I have not dug into it but my guess > is abstraction from what I have heard. > > The scary difficulty here is if after restart input is reporting times > in CLOCK_MONOTONIC and the applications in the namespace are talking > about times in CLOCK_MONOTONIC_SYNC. Then there is an issue. As even > with a fixed offset the times don't match up. > > So a time namespace absolutely needs to do is figure out how to deal > with all of the kernel interfaces reporting times and figure out how to > report them in the current time namespace. So you want to talk to Arnd who is leading the y2038 effort. He knowns how many and which interfaces are involved aside of the obvious core timer ones. It's quite an amount and the problem is that you really need to do that at the interface level, because many of those time stamps are taken in contexts which are completely oblivious of name spaces. Ditto for timeouts and similar things which are handed in through these interfaces. Thanks, tglx
Re: [PATCH] cpufreq: dt-platdev: mark RK3399 as having separate policies per cluster
On Tue, Oct 2, 2018 at 9:41 PM Viresh Kumar wrote:
>
> On 01-10-18, 13:21, Dmitry Torokhov wrote:
> > RK3399 has one cluster with 4 small cores, and another one with 2 big
> > cores, with cores in different clusters having different OPPs and thus
> > different policies. Let's enable this via "have_governor_per_policy"
> > platform data.
>
> The policies are always different in such cases, with or without this flag.
> What
> this flag rather enables is for us to have separate set of tunables for the
> governor for individual policies.
>
> For example, without this flag there will be a single governor directory:
>
> /sys/devices/system/cpu/cpufreq/schedutil/
>
> and the value of tunables in that directory will be used for all cpufreq
> policies.
>
> With this flag you wouldn't have the governor directory there, but rather in:
>
> /sys/devices/system/cpu/cpufreq/policy*/schedutil/
>
> i.e. tunables per policy and that's why the name of the flag is:
> have_governor_per_policy.
>
> > Signed-off-by: Dmitry Torokhov
> > ---
> >
> > Not tested, but we had a patch unconditionally enabling
> > CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag in tree we used to ship devices
> > based on RK3399 platform.
>
> Sure, that sounds good. Just that you need to update the commit log a bit.
OK, I'll do that.
>
> > drivers/cpufreq/cpufreq-dt-platdev.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> > b/drivers/cpufreq/cpufreq-dt-platdev.c
> > index fe14c57de6ca..040ec0f711f9 100644
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst
> > = {
> > { .compatible = "rockchip,rk3328", },
> > { .compatible = "rockchip,rk3366", },
> > { .compatible = "rockchip,rk3368", },
> > - { .compatible = "rockchip,rk3399", },
> > + { .compatible = "rockchip,rk3399",
> > + .data = &(struct cpufreq_dt_platform_data)
>
> data is void *. No need to provide typecast information. This shouldn't throw
> any build warnings I believe.
We however need to tell the compiler the type of structure we are
creating. The following won't compile:
.data = &{ .have_governor_per_policy = true, }
Thanks.
--
Dmitry
[PATCH] stm class: fix a missing-check bug
In stm_char_policy_set_ioctl(), the 'size' field of the struct
'stp_polic_id' is firstly copied from the user space and then checked,
because the length of the 'id' field in this struct, which represents an
identification string, is not fixed. If the 'size' field cannot pass the
check, an error code EINVAL will be returned. However, after the check, the
whole struct is copied again from the user space. Given that the user data
resides in the user space, a malicious user-space process can race to
change the size between the two copies. By doing so, the attacker can
bypass the check on the 'size' field and inject malicious data.
This patch removes the re-copying of the 'size' field in the second copy to
avoid the above issue.
Signed-off-by: Wenwen Wang
---
drivers/hwtracing/stm/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 10bcb5d..7617fb4 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -570,11 +570,13 @@ static int stm_char_policy_set_ioctl(struct stm_file
*stmf, void __user *arg)
if (!id)
return -ENOMEM;
- if (copy_from_user(id, arg, size)) {
+ if (copy_from_user(&id->master, (char __user *)arg + sizeof(size),
+ size - sizeof(size))) {
ret = -EFAULT;
goto err_free;
}
+ id->size = size;
if (id->__reserved_0 || id->__reserved_1)
goto err_free;
--
2.7.4
Re: Setting monotonic time?
Thomas Gleixner writes: > On Tue, 2 Oct 2018, Arnd Bergmann wrote: >> On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote: >> > >> > On Mon, 1 Oct 2018, Eric W. Biederman wrote: >> > > In the context of process migration there is a simpler subproblem that I >> > > think it is worth exploring if we can do something about. >> > > >> > > For a cluster of machines all running with synchronized >> > > clocks. CLOCK_REALTIME matches. CLOCK_MONOTNIC does not match between >> > > machines. Not having a matching CLOCK_MONOTONIC prevents successful >> > > process migration between nodes in that cluster. >> > > >> > > Would it be possible to allow setting CLOCK_MONOTONIC at the very >> > > beginning of time? So that all of the nodes in a cluster can be in >> > > sync? >> > > >> > > No change in skew just in offset for CLOCK_MONOTONIC. >> > > >> > > There are also dragons involved in coordinating things so that >> > > CLOCK_MONOTONIC gets set before CLOCK_MONOTONIC gets used. So I don't >> > > know if allowing CLOCK_MONOTONIC to be set would be practical but it >> > > seems work exploring all on it's own. >> > >> > It's used very early on in the kernel, so that would be a major surprise >> > for many things including user space which has expectations on clock >> > monotonic. >> > >> > It would be reasonably easy to add CLOCK_MONONOTIC_SYNC which can be set in >> > the way you described and then in name spaces make it possible to magically >> > map CLOCK_MONOTONIC to CLOCK_MONOTONIC_SYNC. >> > >> > It still wouldn't allow to have different NTP/PTP time domains, but might >> > be a good start to address the main migration headaches. >> >> If we make CLOCK_MONOTONIC settable this way in a namespace, >> do you think that should include device drivers that report timestamps >> in CLOCK_MONOTONIC base, or only the timekeeping clock and timer >> interfaces? > > Uurgh. That gets messy very fast. > >> Examples for drivers that can report timestamps are input, sound, v4l, >> and drm. I think most of these can report stamps in either monotonic >> or realtime base, while socket timestamps notably are always in >> realtime. >> >> We can probably get away with not setting the timebase for those >> device drivers as long as the checkpoint/restart and migration features >> are not expected to restore the state of an open character device >> in that way. I don't know if that is a reasonable assumption to make >> for the examples I listed. > > No idea. I'm not a container migration wizard. Direct access to hardware/drivers and not through an abstraction like the vfs (an abstraction over block devices) can legitimately be handled by hotplug events. I unplug one keyboard I plug in another. I don't know if the input layer is more of a general abstraction or more of a hardware device. I have not dug into it but my guess is abstraction from what I have heard. The scary difficulty here is if after restart input is reporting times in CLOCK_MONOTONIC and the applications in the namespace are talking about times in CLOCK_MONOTONIC_SYNC. Then there is an issue. As even with a fixed offset the times don't match up. So a time namespace absolutely needs to do is figure out how to deal with all of the kernel interfaces reporting times and figure out how to report them in the current time namespace. Eric
Re: [PATCH] cpufreq: dt-platdev: mark RK3399 as having separate policies per cluster
On 01-10-18, 13:21, Dmitry Torokhov wrote:
> RK3399 has one cluster with 4 small cores, and another one with 2 big
> cores, with cores in different clusters having different OPPs and thus
> different policies. Let's enable this via "have_governor_per_policy"
> platform data.
The policies are always different in such cases, with or without this flag. What
this flag rather enables is for us to have separate set of tunables for the
governor for individual policies.
For example, without this flag there will be a single governor directory:
/sys/devices/system/cpu/cpufreq/schedutil/
and the value of tunables in that directory will be used for all cpufreq
policies.
With this flag you wouldn't have the governor directory there, but rather in:
/sys/devices/system/cpu/cpufreq/policy*/schedutil/
i.e. tunables per policy and that's why the name of the flag is:
have_governor_per_policy.
> Signed-off-by: Dmitry Torokhov
> ---
>
> Not tested, but we had a patch unconditionally enabling
> CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag in tree we used to ship devices
> based on RK3399 platform.
Sure, that sounds good. Just that you need to update the commit log a bit.
> drivers/cpufreq/cpufreq-dt-platdev.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index fe14c57de6ca..040ec0f711f9 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -78,7 +78,10 @@ static const struct of_device_id whitelist[] __initconst =
> {
> { .compatible = "rockchip,rk3328", },
> { .compatible = "rockchip,rk3366", },
> { .compatible = "rockchip,rk3368", },
> - { .compatible = "rockchip,rk3399", },
> + { .compatible = "rockchip,rk3399",
> + .data = &(struct cpufreq_dt_platform_data)
data is void *. No need to provide typecast information. This shouldn't throw
any build warnings I believe.
> + { .have_governor_per_policy = true, },
--
viresh
Re: linux-next: occassional build errors
Hi Stephen,
On Wed, Oct 3, 2018 at 12:51 PM Stephen Rothwell wrote:
>
> Hi Masahiro,
>
> I don't know if that has anything to changes in the kbuild system, but
> since Tuesday, I have been getting random build errors that go away after
> I remove the object directory and build again.
I have no idea.
Is it fine if you use kbuild tree from the last week?
I added 4 kbuild patches this week, but they look irrelevant.
masahiro@pug:~/ref/linux-next$ git log --oneline
next-20180928..next-20181002 | grep kbuild
4712eca8 Merge remote-tracking branch 'kbuild/for-next'
ae5c311 Merge remote-tracking branch 'kbuild-current/fixes'
7163c4d Merge branch 'kbuild' into for-next
7c59867 kbuild: simplify command line creation in scripts/mkmakefile
23d86e8 kbuild: do not pass $(objtree) to scripts/mkmakefile
166011a kbuild: remove user ID check in scripts/mkmakefile
e4db0f7 kbuild: remove VERSION and PATCHLEVEL from $(objtree)/Makefile
> The latest example is this:
>
> include/linux/kconfig.h: file not recognized: file format not recognized
> make[2]: *** [scripts/Makefile.build:492: crypto/crypto_user.o] Error 1
> make[1]: *** [Makefile:1057: crypto] Error 2
> make: *** [Makefile:152: sub-make] Error 2
> Command exited with non-zero status 2
>
> It is always complaining about a .h file ...
>
> Makefile:152 is the MAKE lien below:
>
> # Invoke a second make in the output directory, passing relevant variables
> sub-make:
> $(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
> -f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
>
> Makefile:1057 is the MAKE line below:
>
> PHONY += $(vmlinux-dirs)
> $(vmlinux-dirs): prepare scripts
> $(Q)$(MAKE) $(build)=$@ need-builtin=1
>
> scripts/Makefile.build:492 is the if_changed line below:
>
> $(multi-used-m): FORCE
> $(call if_changed,link_multi-m)
> @{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
>$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
> $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
>
> Not sure what else I can tell you.
>
Does this happen only when building a module?
Can you provide a procedure
to reproduce this?
--
Best Regards
Masahiro Yamada
Re: [PATCH 4.14 114/165] x86/vdso: Fix vDSO build if a retpoline is emitted
On Tue, Oct 2, 2018 at 1:21 AM Nikola Ciprich wrote: > > Hi Greg and others, > > sorry for reporting this so late, but still... > > this breaks build on older compilers, since it requires > -mindirect-branch=thunk-inline -mindirect-branch-register even though > retpoline support is disabled in kernel config.. is this expected? > Nope, my patch was buggy. Can you test the fix I just sent?
[PATCH] x86/vdso: Only enable vDSO retpolines when enabled and supported
When I fixed the vDSO build to use inline retpolines, I messed up
the Makefile logic and made it unconditional. It should have
depended on CONFIG_RETPOLINE and on the availability of compiler
support. This broke the build on some older compilers.
Fixes: 2e549b2ee0e3 ("x86/vdso: Fix vDSO build if a retpoline is emitted")
Cc: sta...@vger.kernel.org
Reported-by: nikola.cipr...@linuxbox.cz
Cc: Thomas Gleixner
Cc: Matt Rickard
Cc: Borislav Petkov
Cc: jason.vas.d...@gmail.com
Cc: David Woodhouse
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: nikola.cipr...@linuxbox.cz
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/vdso/Makefile | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index fa3f439f0a92..141d415a8c80 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -68,7 +68,13 @@ $(obj)/vdso-image-%.c: $(obj)/vdso%.so.dbg $(obj)/vdso%.so
$(obj)/vdso2c FORCE
CFL := $(PROFILING) -mcmodel=small -fPIC -O2 -fasynchronous-unwind-tables -m64
\
$(filter -g%,$(KBUILD_CFLAGS)) $(call cc-option, -fno-stack-protector) \
-fno-omit-frame-pointer -foptimize-sibling-calls \
- -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO $(RETPOLINE_VDSO_CFLAGS)
+ -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
+
+ifdef CONFIG_RETPOLINE
+ifneq ($(RETPOLINE_VDSO_CFLAGS),)
+ CFL += $(RETPOLINE_VDSO_CFLAGS)
+endif
+endif
$(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS)
$(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
@@ -138,7 +144,13 @@ KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector)
KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
KBUILD_CFLAGS_32 += -fno-omit-frame-pointer
KBUILD_CFLAGS_32 += -DDISABLE_BRANCH_PROFILING
-KBUILD_CFLAGS_32 += $(RETPOLINE_VDSO_CFLAGS)
+
+ifdef CONFIG_RETPOLINE
+ifneq ($(RETPOLINE_VDSO_CFLAGS),)
+ KBUILD_CFLAGS_32 += $(RETPOLINE_VDSO_CFLAGS)
+endif
+endif
+
$(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
$(obj)/vdso32.so.dbg: FORCE \
--
2.17.1
linux-next: occassional build errors
Hi Masahiro,
I don't know if that has anything to changes in the kbuild system, but
since Tuesday, I have been getting random build errors that go away after
I remove the object directory and build again. The latest example is this:
include/linux/kconfig.h: file not recognized: file format not recognized
make[2]: *** [scripts/Makefile.build:492: crypto/crypto_user.o] Error 1
make[1]: *** [Makefile:1057: crypto] Error 2
make: *** [Makefile:152: sub-make] Error 2
Command exited with non-zero status 2
It is always complaining about a .h file ...
Makefile:152 is the MAKE lien below:
# Invoke a second make in the output directory, passing relevant variables
sub-make:
$(Q)$(MAKE) -C $(KBUILD_OUTPUT) KBUILD_SRC=$(CURDIR) \
-f $(CURDIR)/Makefile $(filter-out _all sub-make,$(MAKECMDGOALS))
Makefile:1057 is the MAKE line below:
PHONY += $(vmlinux-dirs)
$(vmlinux-dirs): prepare scripts
$(Q)$(MAKE) $(build)=$@ need-builtin=1
scripts/Makefile.build:492 is the if_changed line below:
$(multi-used-m): FORCE
$(call if_changed,link_multi-m)
@{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
$(call multi_depend, $(multi-used-m), .o, -objs -y -m)
Not sure what else I can tell you.
--
Cheers,
Stephen Rothwell
pgpxd3Qr8UZX0.pgp
Description: OpenPGP digital signature
Re: [PATCH] perf record: use unmapped IP for inline callchain cursors
On 10/02/2018 09:02 PM, Arnaldo Carvalho de Melo wrote: > Em Tue, Oct 02, 2018 at 09:39:49AM +0200, Milian Wolff escreveu: >> Only use the mapped IP to find inline frames, but keep >> using the unmapped IP for the callchain cursor. This >> ensures we properly show the unmapped IP when displaying >> a frame we received via the dso__parse_addr_inlines API >> for a module which does not contain sufficient debug symbols >> to show the srcline. > > So, the patch came mangled, I fixed it up, please check, I'm adding Ravi > to the CC list, so that he can check as well and retest, right Ravi? > > - Arnaldo > > From d9ddee9653d5676130471de9bc688fc7ec7b4fc4 Mon Sep 17 00:00:00 2001 > From: Milian Wolff > Date: Tue, 2 Oct 2018 09:39:49 +0200 > Subject: [PATCH 1/1] perf record: use unmapped IP for inline callchain cursors > > Only use the mapped IP to find inline frames, but keep using the unmapped IP > for the callchain cursor. This ensures we properly show the unmapped IP when > displaying a frame we received via the dso__parse_addr_inlines API for a > module > which does not contain sufficient debug symbols to show the srcline. > > Before: > > $ perf record -e cycles:u --call-graph ls > $ perf script > ... > ls 12853 2735.563911: 43354 cycles:u: > 17878 __GI___tunables_init+0x01d1d63a0118 > (/usr/lib/ld-2.28.so) > 19ee9 _dl_sysdep_start+0x01d1d63a02e9 > (/usr/lib/ld-2.28.so) > 3087 _dl_start+0x01d1d63a0287 (/usr/lib/ld-2.28.so) > 2007 _start+0x01d1d63a0007 (/usr/lib/ld-2.28.so) > > After: > > $ perf script > ... > ls 12853 2735.563911: 43354 cycles:u: > 7f1714e46878 __GI___tunables_init+0x118 (/usr/lib/ld-2.28.so) > 7f1714e48ee9 _dl_sysdep_start+0x2e9 (/usr/lib/ld-2.28.so) > 7f1714e32087 _dl_start+0x287 (/usr/lib/ld-2.28.so) > 7f1714e31007 _start+0x7 (/usr/lib/ld-2.28.so) With current perf/urgent: $ sudo ./perf record --call-graph=dwarf -e probe_libc:inet_pton -- ping -6 -c 1 ::1 $ sudo ./perf script ping 4109 [011] 767269.031273: probe_libc:inet_pton: (7fff944cb458) 15b458 __inet_pton+0xd7920008 (inlined) 10feb3 gaih_inet.constprop.7+0xd7920f43 (/usr/lib64/libc-2.26. 110a13 __GI_getaddrinfo+0xd7920163 (inlined) 13c752d6f _init+0xbfb (/usr/bin/ping) 2371f generic_start_main.isra.0+0xd792013f (/usr/lib64/libc-2 2391b __libc_start_main+0xd79200bb (/usr/lib64/libc-2.26.so) With this patch: $ sudo ./perf script ping 4109 [011] 767269.031273: probe_libc:inet_pton: (7fff944cb458) 7fff944cb458 __inet_pton+0x8 (inlined) 7fff9447feb3 gaih_inet.constprop.7+0xf43 (/usr/lib64/libc-2.26.so) 7fff94480a13 __GI_getaddrinfo+0x163 (inlined) 13c752d6f _init+0xbfb (/usr/bin/ping) 7fff9439371f generic_start_main.isra.0+0x13f (/usr/lib64/libc-2.26.so) 7fff9439391b __libc_start_main+0xbb (/usr/lib64/libc-2.26.so) LGTM. Tested-by: Ravi Bangoria
Re: [PATCH v3 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap
Christoph Hellwig 於 2018年10月2日 週二 下午10:51寫道： > > On Tue, Oct 02, 2018 at 04:52:31PM +0800, Zong Li wrote: > > From: Vincent Chen > > > > For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero > > after AND with PAGE_MASK because the data type of PAGE_MASK is > > unsigned long. To fix this problem, the page alignment is done by > > subtracting the page offset instead of AND with PAGE_MASK. > > > > Signed-off-by: Vincent Chen > > Looks good, > > Reviewed-by: Christoph Hellwig > > (and I'm pretty sure I reviewed this before..) Hi Christoph, Very sorry about that. I didn't notice I lose these review tags. Could you please help to review again in version 4 patches? Thank you. Regards, Zong
[PATCH v4 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines
Add umoddi3 and udivmoddi4 support for 32-bit.
The RV32 need the umoddi3 to do modulo when the operands are long long
type, like other libraries implementation such as ucmpdi2, lshrdi3 and
so on.
I encounter the undefined reference 'umoddi3' when I use the in
house dma driver, although it is in house driver, but I think that
umoddi3 is a common function for RV32.
The udivmoddi4 and umoddi3 are copies from libgcc in gcc 4.2.1.
There are other functions use the udivmoddi4 in libgcc, so I separate
the umoddi3 and udivmoddi4 for flexible extension in the future.
Signed-off-by: Zong Li
---
lib/Kconfig | 3 +
lib/Makefile | 1 +
lib/udivmoddi4.c | 326 +++
lib/umoddi3.c| 48
4 files changed, 378 insertions(+)
create mode 100644 lib/udivmoddi4.c
create mode 100644 lib/umoddi3.c
diff --git a/lib/Kconfig b/lib/Kconfig
index a3928d4..d82f206 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -621,3 +621,6 @@ config GENERIC_LIB_CMPDI2
config GENERIC_LIB_UCMPDI2
bool
+
+config GENERIC_LIB_UMODDI3
+ bool
diff --git a/lib/Makefile b/lib/Makefile
index ca3f7eb..51bf24d 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -271,3 +271,4 @@ obj-$(CONFIG_GENERIC_LIB_LSHRDI3) += lshrdi3.o
obj-$(CONFIG_GENERIC_LIB_MULDI3) += muldi3.o
obj-$(CONFIG_GENERIC_LIB_CMPDI2) += cmpdi2.o
obj-$(CONFIG_GENERIC_LIB_UCMPDI2) += ucmpdi2.o
+obj-$(CONFIG_GENERIC_LIB_UMODDI3) += umoddi3.o udivmoddi4.o
diff --git a/lib/udivmoddi4.c b/lib/udivmoddi4.c
new file mode 100644
index 000..ddbe4fa
--- /dev/null
+++ b/lib/udivmoddi4.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* More subroutines needed by GCC output code on some machines. */
+/* Compile this one with gcc. */
+/* Copyright (C) 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
+ * 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
+ *
+ * This file is part of GCC.
+ *
+ * GCC 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, or (at your option) any later
+ * version.
+ *
+ * In addition to the permissions in the GNU General Public License, the
+ * Free Software Foundation gives you unlimited permission to link the
+ * compiled version of this file into combinations with other programs,
+ * and to distribute those combinations without any restriction coming
+ * from the use of this file. (The General Public License restrictions
+ * do apply in other respects; for example, they cover modification of
+ * the file, and distribution when not linked into a combine
+ * executable.)
+ *
+ * GCC 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GCC; see the file COPYING. If not, write to the Free
+ * Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include
+
+#define count_leading_zeros(COUNT, X) ((COUNT) = __builtin_clz(X))
+
+#define W_TYPE_SIZE 32
+
+#define __ll_B ((unsigned long) 1 << (W_TYPE_SIZE / 2))
+#define __ll_lowpart(t) ((unsigned long) (t) & (__ll_B - 1))
+#define __ll_highpart(t) ((unsigned long) (t) >> (W_TYPE_SIZE / 2))
+
+/* If we still don't have umul_ppmm, define it using plain C. */
+#if !defined(umul_ppmm)
+#define umul_ppmm(w1, w0, u, v)
\
+ do {\
+ unsigned long __x0, __x1, __x2, __x3; \
+ unsigned short __ul, __vl, __uh, __vh; \
+ \
+ __ul = __ll_lowpart(u); \
+ __uh = __ll_highpart(u);\
+ __vl = __ll_lowpart(v); \
+ __vh = __ll_highpart(v);\
+ \
+ __x0 = (unsigned long) __ul * __vl; \
+ __x1 = (unsigned long) __ul * __vh; \
+ __x2 = (unsigned long) __uh * __vl; \
+ __x3 = (unsigned long) __uh * __vh; \
+ \
+ __x1 += __ll_highpart(__x0);\
+ __x1 += __x2; \
+ if (__x1 < __x2)\
+ __x3 += __ll_B; \
[PATCH v4 4/5] RISC-V: Select GENERIC_LIB_UMODDI3 on RV32
On RV32, it will use the __umoddi3. Select GENERIC_LIB_UMODDI3 to avoid undefined reference. Signed-off-by: Zong Li --- arch/riscv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index a344980..dc262fa 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -108,6 +108,7 @@ config ARCH_RV32I select GENERIC_LIB_ASHRDI3 select GENERIC_LIB_LSHRDI3 select GENERIC_LIB_UCMPDI2 + select GENERIC_LIB_UMODDI3 config ARCH_RV64I bool "RV64I" -- 2.7.4
[PATCH v4 1/5] RISC-V: Build tishift only on 64-bit
Only RV64 supports 128 integer size. Signed-off-by: Zong Li --- arch/riscv/lib/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 445ec84..5739bd0 100644 --- a/arch/riscv/lib/Makefile +++ b/arch/riscv/lib/Makefile @@ -2,6 +2,7 @@ lib-y += delay.o lib-y += memcpy.o lib-y += memset.o lib-y += uaccess.o -lib-y += tishift.o + +lib-(CONFIG_64BIT) += tishift.o lib-$(CONFIG_32BIT) += udivdi3.o -- 2.7.4
[PATCH v4 0/5] Fix some bugs on RV32 build fail and issue
This patches contain the modificaion as follows: 1. Fix up the building fail on RV32. 2. Add umoddi3 and udivmoddi4 functions for RV32. 3. Fix ioremap problem on RV32. Thanks all for review these code and modify the copyright description. Changes in v4: - Retain the complete copyright description. - Modify commit message. - Rebase upstream code. Changes in v3: - Change the copyright notices to GPLv2 from gcc 4.2.1. Changes in v2: - Retain the copyright notices from libgcc in umoddi3.c and udivmoddi4.c. Vincent Chen (1): RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap Zong Li (4): RISC-V: Build tishift only on 64-bit RISC-V: Add preprocessor directive for swiotlb lib: Add umoddi3 and udivmoddi4 of GCC library routines RISC-V: Select GENERIC_LIB_UMODDI3 on RV32 arch/riscv/Kconfig| 1 + arch/riscv/kernel/setup.c | 3 + arch/riscv/lib/Makefile | 3 +- arch/riscv/mm/ioremap.c | 2 +- lib/Kconfig | 3 + lib/Makefile | 1 + lib/udivmoddi4.c | 326 ++ lib/umoddi3.c | 48 +++ 8 files changed, 385 insertions(+), 2 deletions(-) create mode 100644 lib/udivmoddi4.c create mode 100644 lib/umoddi3.c -- 2.7.4
[PATCH v4 2/5] RISC-V: Add preprocessor directive for swiotlb
On RV32, it doesn't select the SWIOTLB, only RV64 support swiotlb now. Signed-off-by: Zong Li --- arch/riscv/kernel/setup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c index aee6031..6de6584 100644 --- a/arch/riscv/kernel/setup.c +++ b/arch/riscv/kernel/setup.c @@ -227,7 +227,10 @@ void __init setup_arch(char **cmdline_p) setup_bootmem(); paging_init(); unflatten_device_tree(); + +#ifdef CONFIG_SWIOTLB swiotlb_init(1); +#endif #ifdef CONFIG_SMP setup_smp(); -- 2.7.4
[PATCH v4 5/5] RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap
From: Vincent Chen For 32bit, the upper 32-bit of phys_addr_t will be flushed to zero after AND with PAGE_MASK because the data type of PAGE_MASK is unsigned long. To fix this problem, the page alignment is done by subtracting the page offset instead of AND with PAGE_MASK. Signed-off-by: Vincent Chen --- arch/riscv/mm/ioremap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/mm/ioremap.c b/arch/riscv/mm/ioremap.c index 70ef272..bd2f2db 100644 --- a/arch/riscv/mm/ioremap.c +++ b/arch/riscv/mm/ioremap.c @@ -42,7 +42,7 @@ static void __iomem *__ioremap_caller(phys_addr_t addr, size_t size, /* Page-align mappings */ offset = addr & (~PAGE_MASK); - addr &= PAGE_MASK; + addr -= offset; size = PAGE_ALIGN(size + offset); area = get_vm_area_caller(size, VM_IOREMAP, caller); -- 2.7.4
Re: [ftrace/kprobes PATCH 0/3] tracing: probeevent: Fix module symbol probing
On Mon, 1 Oct 2018 11:48:55 -0400 Steven Rostedt wrote: > On Thu, 27 Sep 2018 19:48:58 +0900 > Masami Hiramatsu wrote: > > > Hello Steve, > > > > Could you also include this series to the branch? > > > > Hi Masami, > > I just came back from Embedded / Kernel Recipes, I'll look at these > today. > Unfortunately, I've been pulled off to other tasks :-( I'll make it a priority tomorrow (Wednesday). -- Steve
Re: rcu: Kernel stack is corrupted in: perf_trace_rcu_dyntick
On Sat, 29 Sep 2018 17:22:13 +0800 王晓东 wrote: > Hi there, > > We would like to report a kernel stack corrupted problem we identified > in the perf_trace_rcu_dyntick function of tracing events subsystem. > And the problem was founded by syzkaller. We has tested the PoC on > the lasted master branch of kernel(4.19.0-rc5+). > > The crash log generated with KASAN enabled: > > root@pc:~# ./perf_trace_rcu_dyntick > [ 582.069938] Kernel panic - not syncing: stack-protector: Kernel > stack is corrupted in: perf_trace_rcu_dyntick+0x355/0x4f0 > [ 582.069938] > [ 582.071341] CPU: 6 PID: 3417 Comm: perf_trace_rcu_ Not tainted 4.19.0-rc5+ > #1 > [ 582.072134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 > [ 582.073103] Call Trace: > [ 582.073364] > [ 582.073614] dump_stack+0x8c/0xce > [ 582.074039] panic+0x1cb/0x3aa > [ 582.074427] ? refcount_error_report+0x296/0x296 > [ 582.075003] ? timerqueue_del+0x71/0x130 > [ 582.075553] ? perf_trace_rcu_dyntick+0x355/0x4f0 > [ 582.076063] ? __stack_chk_fail+0x6/0x20 > [ 582.076763] ? perf_trace_rcu_dyntick+0x355/0x4f0 > [ 582.077369] __stack_chk_fail+0x1f/0x20 > [ 582.077877] perf_trace_rcu_dyntick+0x355/0x4f0 > [ 582.078442] ? rcu_gp_is_expedited+0xa0/0xa0 > [ 582.078993] ? rcu_gp_is_expedited+0xa0/0xa0 > [ 582.079525] ? check_preempt_curr+0x1c2/0x2a0 > [ 582.080059] ? sched_clock_cpu+0x18/0x160 > [ 582.080551] rcu_nmi_enter+0x1f0/0x2f0 > [ 582.081036] ? rcu_gp_is_expedited+0xa0/0xa0 > [ 582.081507] irq_enter+0xf/0x80 > [ 582.081914] smp_apic_timer_interrupt+0x1b/0x2d0 > [ 582.082480] apic_timer_interrupt+0xf/0x20 > [ 582.082984] > [ 582.083219] RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x50 > [ 582.087816] Code: e8 35 0b 20 00 48 8b 14 24 e9 fe fe ff ff 48 89 > df e8 24 0b 20 00 e9 d9 fe ff ff 4c 89 e7 e8 17 0b 20 00 e9 ab fe ff > ff 90 90 <65> 48 8b 04 25 40 dd 01 00 65 8b 15 70 03 8f 63 81 e2 00 01 > 1f 00 > [ 582.090289] RSP: 0018:8800651bf9e0 EFLAGS: 0206 ORIG_RAX: > ff13 > [ 582.091238] RAX: RBX: 9eed12a5 RCX: > 9c6ca1b6 > [ 582.092873] RDX: 0005 RSI: 9ee31d71 RDI: > 9eed12a4 > [ 582.093934] RBP: 0078 R08: ed000d38dfb2 R09: > ed000d38dfb1 > [ 582.095102] R10: 7350a3ba R11: 880069c6fd8f R12: > 8800651bfa6e > [ 582.096444] R13: 0001 R14: dc00 R15: > 006a > [ 582.097414] ? kallsyms_expand_symbol.constprop.11+0x176/0x250 > [ 582.098518] kallsyms_expand_symbol.constprop.11+0x12e/0x250 > [ 582.099707] kallsyms_lookup_name+0xbe/0x1d0 > [ 582.100369] ? kallsyms_on_each_symbol+0x210/0x210 > [ 582.101436] ? snprintf+0xbd/0xf0 > [ 582.102029] ? vsprintf+0x30/0x30 > [ 582.102805] ? kasan_kmalloc+0xa9/0xd0 > [ 582.103489] ? alloc_trace_kprobe+0x6c0/0x930 > [ 582.104073] kprobe_on_func_entry+0x57/0xb0 I'm curious to what kretprobe was used. -- Steve > [ 582.105421] register_kretprobe+0x89/0xc10 > [ 582.105930] ? set_print_fmt+0x32/0xa0 > [ 582.106376] __register_trace_kprobe.part.10+0x14e/0x2e0 > [ 582.106980] create_local_trace_kprobe+0x29c/0x3f0 > [ 582.107487] perf_kprobe_init+0x15f/0x210 > [ 582.107912] perf_kprobe_event_init+0xc4/0x140 > [ 582.108377] perf_try_init_event+0xcb/0x290 > [ 582.108817] perf_event_alloc+0x1476/0x2020 > [ 582.109264] ? find_get_context.isra.106+0x690/0x690 > [ 582.109922] ? __alloc_fd+0x1a3/0x4e0 > [ 582.120002] __do_sys_perf_event_open+0x222/0x1f40 > [ 582.123049] ? avc_has_perm_noaudit+0x340/0x340 > [ 582.131226] ? perf_event_set_output+0x5f0/0x5f0 > [ 582.134395] ? handle_mm_fault+0x103/0x350 > [ 582.138102] ? ksys_ioctl+0x61/0x90 > [ 582.140234] do_syscall_64+0x9a/0x2c0 > [ 582.142674] ? prepare_exit_to_usermode+0xbc/0x150 > [ 582.146856] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 582.151127] RIP: 0033:0x446159 > [ 582.152816] Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 > 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 > 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 08 fc ff c3 66 2e 0f 1f 84 00 00 > 00 00 > [ 582.167257] RSP: 002b:7fffc2b023d8 EFLAGS: 0246 ORIG_RAX: > 012a > [ 582.171375] RAX: ffda RBX: 004002c8 RCX: > 00446159 > [ 582.175760] RDX: RSI: RDI: > 2180 > [ 582.176487] RBP: 7fffc2b025b0 R08: R09: > > [ 582.177189] R10: R11: 0246 R12: > 00406e40 > [ 582.177898] R13: 00406ed0 R14: R15: > > [ 583.353322] Shutting down cpus with NMI > [ 583.354285] Kernel Offset: 0x1b40 from 0x8100 > (relocation range: 0x8000-0xbfff) > [ 583.356743] Rebooting in 86400 seconds.. > > > This bug could be easily reproduced by running the PoC(generated by >
Re: [PATCH] ARM: dts: imx6sx-sdb: Fix enet phy regulator
Hi Leonard, On Tue, Oct 2, 2018 at 3:42 PM Leonard Crestez wrote: > @@ -371,10 +372,12 @@ > MX6SX_PAD_RGMII1_RD1__ENET1_RX_DATA_1 0x3081 > MX6SX_PAD_RGMII1_RD2__ENET1_RX_DATA_2 0x3081 > MX6SX_PAD_RGMII1_RD3__ENET1_RX_DATA_3 0x3081 > MX6SX_PAD_RGMII1_RX_CTL__ENET1_RX_EN0x3081 > MX6SX_PAD_ENET2_RX_CLK__ENET2_REF_CLK_25M > 0x91 > + /* phy reset */ > + MX6SX_PAD_ENET2_CRS__GPIO2_IO_7 > 0x8000 We should avoid using 0x8000 as this relies on the bootloader setting the IOMUX. Please do like this insted: MX6SX_PAD_ENET2_CRS__GPIO2_IO_7 0x10b0 Then you can add: Reviewed-by: Fabio Estevam
Re: [PATCH] fs/ext4: Convert fault handler to use vm_fault_t type
On Mon, Sep 10, 2018 at 09:16:12PM +0530, Souptick Joarder wrote: > Return type of ext4_page_mkwrite and ext4_filemap_fault are > changed to use vm_fault_t type. > > With this patch all the callers of block_page_mkwrite_return() > are changed to handle vm_fault_t. So converting the return type > of block_page_mkwrite_return() to vm_fault_t. > > Signed-off-by: Souptick Joarder Thanks, applied. - Ted
Re: [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration
On 10/02/2018 06:09 PM, Michal Hocko wrote: > On Tue 02-10-18 17:45:28, Anshuman Khandual wrote: >> Architectures like arm64 have PUD level HugeTLB pages for certain configs >> (1GB huge page is PUD based on ARM64_4K_PAGES base page size) that can be >> enabled for migration. It can be achieved through checking for PUD_SHIFT >> order based HugeTLB pages during migration. > > Well a long term problem with hugepage_migration_supported is that it is > used in two different context 1) to bail out from the migration early > because the arch doesn't support migration at all and 2) to use movable > zone for hugetlb pages allocation. I am especially concerned about the > later because the mere support for migration is not really good enough. > Are you really able to find a different giga page during the runtime to > move an existing giga page out of the movable zone? I pre-allocate them before trying to initiate the migration (soft offline in my experiments). Hence it should come from the pre-allocated HugeTLB pool instead from the buddy. I might be missing something here but do we ever allocate HugeTLB on the go when trying to migrate ? IIUC it always came from the pool (unless its something related to ovecommit/surplus). Could you please kindly explain regarding how migration target HugeTLB pages are allocated on the fly from movable zone. But even if there are some chances of run time allocation failure from movable zone (as in point 2) that should not block the very initiation of migration itself. IIUC thats not the semantics for either THP or normal pages. Why should it be different here. If the allocation fails we should report and abort as always. Its the caller of migration taking the chances. why should we prevent that. > > So I guess we want to split this into two functions > arch_hugepage_migration_supported and hugepage_movable. The later would So the set difference between arch_hugepage_migration_supported and hugepage_movable still remains un-migratable ? Then what is the purpose for arch_hugepage_migration_supported page size set in the first place. Does it mean we allow the migration at the beginning and the abort later when the page size does not fall within the subset for hugepage_movable. Could you please kindly explain this in more detail. > be a reasonably migrateable subset of the former. Without that this > patch migth introduce subtle regressions when somebody relies on movable > zone to be really movable. PUD based HugeTLB pages were never migratable, then how can there be any regression here ? At present we even support PGD based HugeTLB pages for migration. Wondering how PUD based ones are going to be any different.
Re: [GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.20
Hi Arnd, Olof, Please hold on. I've received a little more patches. I will queue up them, and send a respin later on. Thanks. On Wed, Oct 3, 2018 at 8:47 AM Masahiro Yamada wrote: > > Hi Arnd, Olof, > > Please pull UniPhier DT updates for the v4.20 MW. > > In this cycle, I queued up all arm/arm64 changes > into a single branch to avoid build errors. > > Thanks! > > > > > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git > tags/uniphier-dt-v4.20 > > for you to fetch changes up to 84a9c4d55907feece68c6012d3c030cf5c841ceb: > > arm64: dts: uniphier: add SD controller nodes (2018-10-03 08:21:27 +0900) > > > UniPhier ARM SoC DT updates for v4.20 > > - Add more clocks to NAND controller nodes > > - Add SPI controller nodes > > - Add SD controller nodes > > > Kunihiko Hayashi (3): > ARM: dts: uniphier: add SPI pin-mux node > ARM: dts: uniphier: add SPI node for UniPhier 32bit SoCs > arm64: dts: uniphier: add SPI node for LD20, LD11 and PXs3 > > Masahiro Yamada (4): > ARM: uniphier: dts: add more clocks to Denali NAND controller node > arm64: uniphier: dts: add more clocks to Denali NAND controller node > ARM: dts: uniphier: add SD/eMMC controller nodes > arm64: dts: uniphier: add SD controller nodes > > arch/arm/boot/dts/uniphier-ld4-ref.dts| 4 ++ > arch/arm/boot/dts/uniphier-ld4.dtsi | 48 ++- > arch/arm/boot/dts/uniphier-ld6b-ref.dts | 4 ++ > arch/arm/boot/dts/uniphier-pinctrl.dtsi | 25 > arch/arm/boot/dts/uniphier-pro4-ace.dts | 4 ++ > arch/arm/boot/dts/uniphier-pro4-ref.dts | 4 ++ > arch/arm/boot/dts/uniphier-pro4-sanji.dts | 4 ++ > arch/arm/boot/dts/uniphier-pro4.dtsi | 62 +++- > arch/arm/boot/dts/uniphier-pro5.dtsi | 59 ++- > arch/arm/boot/dts/uniphier-pxs2-gentil.dts| 4 ++ > arch/arm/boot/dts/uniphier-pxs2-vodka.dts | 4 ++ > arch/arm/boot/dts/uniphier-pxs2.dtsi | 59 ++- > arch/arm/boot/dts/uniphier-sld8-ref.dts | 4 ++ > arch/arm/boot/dts/uniphier-sld8.dtsi | 48 ++- > arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 25 +++- > arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 61 ++- > .../boot/dts/socionext/uniphier-pxs3-ref.dts | 4 ++ > arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 43 +- > 18 files changed, 458 insertions(+), 8 deletions(-) > > > -- > Best Regards > Masahiro Yamada -- Best Regards Masahiro Yamada
Urgent,
Hello Please i still await your response regarding my previous email.
Re: [PATCH v3 3/3] iio: magnetometer: Add driver support for PNI RM3100
G'day Song,
Noticed a one more thing below
On 2/10/2018 10:38 PM, Song Qiang wrote:
PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with a MagI2C
interface.
Following functions are available:
- Single-shot measurement from
/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
- Triggerd buffer measurement.
- Both i2c and spi interface are supported.
- Both interrupt and polling measurement is supported, depends on if
the 'interrupts' in DT is declared.
Signed-off-by: Song Qiang
---
MAINTAINERS| 7 +
drivers/iio/magnetometer/Kconfig | 29 ++
drivers/iio/magnetometer/Makefile | 4 +
drivers/iio/magnetometer/rm3100-core.c | 539 +
drivers/iio/magnetometer/rm3100-i2c.c | 58 +++
drivers/iio/magnetometer/rm3100-spi.c | 64 +++
drivers/iio/magnetometer/rm3100.h | 17 +
7 files changed, 718 insertions(+)
create mode 100644 drivers/iio/magnetometer/rm3100-core.c
create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
create mode 100644 drivers/iio/magnetometer/rm3100.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 967ce8cdd1cc..14eeeb072403 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11393,6 +11393,13 @@ M: "Rafael J. Wysocki"
S:Maintained
F:drivers/pnp/
+PNI RM3100 IIO DRIVER
+M: Song Qiang
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/iio/magnetometer/rm3100*
+F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
+
POSIX CLOCKS and TIMERS
M:Thomas Gleixner
L:linux-kernel@vger.kernel.org
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index ed9d776d01af..8a63cbbca4b7 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -175,4 +175,33 @@ config SENSORS_HMC5843_SPI
- hmc5843_core (core functions)
- hmc5843_spi (support for HMC5983)
+config SENSORS_RM3100
+ tristate
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+
+config SENSORS_RM3100_I2C
+ tristate "PNI RM3100 3-Axis Magnetometer (I2C)"
+ depends on I2C
+ select SENSORS_RM3100
+ select REGMAP_I2C
+ help
+ Say Y here to add support for the PNI RM3100 3-Axis Magnetometer.
+
+ This driver can also be compiled as a module.
+ To compile this driver as a module, choose M here: the module
+ will be called rm3100-i2c.
+
+config SENSORS_RM3100_SPI
+ tristate "PNI RM3100 3-Axis Magnetometer (SPI)"
+ depends on SPI_MASTER
+ select SENSORS_RM3100
+ select REGMAP_SPI
+ help
+ Say Y here to add support for the PNI RM3100 3-Axis Magnetometer.
+
+ This driver can also be compiled as a module.
+ To compile this driver as a module, choose M here: the module
+ will be called rm3100-spi.
+
endmenu
diff --git a/drivers/iio/magnetometer/Makefile
b/drivers/iio/magnetometer/Makefile
index 664b2f866472..ba1bc34b82fa 100644
--- a/drivers/iio/magnetometer/Makefile
+++ b/drivers/iio/magnetometer/Makefile
@@ -24,3 +24,7 @@ obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o
obj-$(CONFIG_SENSORS_HMC5843) += hmc5843_core.o
obj-$(CONFIG_SENSORS_HMC5843_I2C) += hmc5843_i2c.o
obj-$(CONFIG_SENSORS_HMC5843_SPI) += hmc5843_spi.o
+
+obj-$(CONFIG_SENSORS_RM3100) += rm3100-core.o
+obj-$(CONFIG_SENSORS_RM3100_I2C) += rm3100-i2c.o
+obj-$(CONFIG_SENSORS_RM3100_SPI) += rm3100-spi.o
diff --git a/drivers/iio/magnetometer/rm3100-core.c
b/drivers/iio/magnetometer/rm3100-core.c
new file mode 100644
index ..cacdaee28ae3
--- /dev/null
+++ b/drivers/iio/magnetometer/rm3100-core.c
@@ -0,0 +1,539 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PNI RM3100 3-axis geomagnetic sensor driver core.
+ *
+ * Copyright (C) 2018 Song Qiang
+ *
+ * User Manual available at
+ *
Urgent,
Hello Please i still await your response regarding my previous email.
Re: [PATCH v3 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines
Palmer Dabbelt 於 2018年10月2日 週二 下午11:02寫道： > > On Tue, 02 Oct 2018 07:50:41 PDT (-0700), Christoph Hellwig wrote: > >> The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other > >> functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and > >> udivmoddi4 for flexible extension in the future. > > > > Can you please mention which exact version of an external projected > > you imported things from? That will generally help if/when someone > > has to dig into diverging versions. > > > >> +++ b/lib/udivmoddi4.c > >> @@ -0,0 +1,310 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> + > >> +/* > >> + * 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. > >> + * > >> + * You should have received a copy of the GNU General Public License > >> + * along with this program; if not, see the file COPYING, or write > >> + * to the Free Software Foundation, Inc. > >> + */ > > > > The SPDX tag was supposed to replace this boiler plate. On the other > > hand I'm surpriced there is no Copyright statement here - the FSF is > > usually very good about having them uptodate in every GNU project. > > I suggested he import the gcc-4.2.1 version, which has a big copyright notice > > /* More subroutines needed by GCC output code on some machines. */ > /* Compile this one with gcc. */ > /* Copyright (C) 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, >2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc. > > This file is part of GCC. > > GCC 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, or (at your option) any later > version. > > In addition to the permissions in the GNU General Public License, the > Free Software Foundation gives you unlimited permission to link the > compiled version of this file into combinations with other programs, > and to distribute those combinations without any restriction coming > from the use of this file. (The General Public License restrictions > do apply in other respects; for example, they cover modification of > the file, and distribution when not linked into a combine > executable.) > > GCC 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. > > You should have received a copy of the GNU General Public License > along with GCC; see the file COPYING. If not, write to the Free > Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA > 02110-1301, USA. */ > > so it looks like something went wrong here. Zong: did you go back and > re-construct this function from the GPLv2 source? Yes, I re-construct this function from GCC 4.2.1. The copyright part, I referred to the other GCC routine copies in kernel such as ucmpdi2, muldi3, ashldi3 and so on, I found they removed the 'GCC' string, so I use the same copyright from these files. I will re-write the copyright part and submit the next version. Thanks to all for help.
[PATCH v6 3/3] Documentation/kernel-parameters.txt: Document rand_mem_physical_padding=
This kernel parameter allows the modification of the padding used for the physical memory mapping section when KASLR memory is enabled. For memory hotplug capable systems, the default padding size, CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, may not be enough. The option is useful to adjust the padding size. Signed-off-by: Masayoshi Mizuma --- .../admin-guide/kernel-parameters.txt | 19 +++ 1 file changed, 19 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 92eb1f4..f0930e3 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3529,6 +3529,25 @@ fully seed the kernel's CRNG. Default is controlled by CONFIG_RANDOM_TRUST_CPU. + rand_mem_physical_padding= + [KNL] Define the padding size in terabytes + used for the physical memory mapping section + when KASLR is enabled. + If the padding size is not enough, you can see + 'Set rand_mem_physical_padding=XX ...' in system + boot message, so set the parameter as the message + suggests. + + This parameter is useful for memory hot-add capable + systems. Such systems may have more space than + actual memory size to hot-add memory. If the + padding size is not enough and memory is hot-added, + the hot-adding will fail because it destroys the + system memory map. So, the padding size needs to be + adjusted in such a system. + The default value is the value of + CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING. + ras=option[,option,...] [KNL] RAS-specific options cec_disable [X86] -- 2.18.0
[PATCH v6 1/3] x86/mm: Add a kernel parameter to change the padding used for the physical memory mapping
If each node of physical memory layout has huge space for hotplug,
the padding used for the physical memory mapping section is not enough.
For exapmle of the layout:
SRAT: Node 6 PXM 4 [mem 0x1000-0x13ff] hotplug
SRAT: Node 7 PXM 5 [mem 0x1400-0x17ff] hotplug
SRAT: Node 2 PXM 6 [mem 0x1800-0x1bff] hotplug
SRAT: Node 3 PXM 7 [mem 0x1c00-0x1fff] hotplug
We can increase the padding via CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
however, the needed padding size depends on the system environment.
The kernel option is better than changing the config.
Signed-off-by: Masayoshi Mizuma
Reviewed-by: Baoquan He
---
arch/x86/include/asm/setup.h | 9 +
arch/x86/mm/kaslr.c | 22 +-
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ae13bc9..1765a15 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -80,6 +80,15 @@ static inline unsigned long kaslr_offset(void)
return (unsigned long)&_text - __START_KERNEL;
}
+#ifdef CONFIG_RANDOMIZE_MEMORY
+extern inline int __init get_rand_mem_physical_padding(void);
+#else
+static inline int __init get_rand_mem_physical_padding(void)
+{
+ return 0;
+}
+#endif
+
/*
* Do NOT EVER look at the BIOS memory size location.
* It does not work on many machines.
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 61db77b..eb47f05 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -40,6 +40,7 @@
*/
static const unsigned long vaddr_end = CPU_ENTRY_AREA_BASE;
+static int rand_mem_physical_padding __initdata =
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
/*
* Memory regions randomized by KASLR (except modules that use a separate logic
* earlier during boot). The list is ordered based on virtual addresses. This
@@ -69,6 +70,25 @@ static inline bool kaslr_memory_enabled(void)
return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
}
+inline int __init get_rand_mem_physical_padding(void)
+{
+ return rand_mem_physical_padding;
+}
+
+static int __init rand_mem_physical_padding_setup(char *str)
+{
+ int max_padding = (1 << (MAX_PHYSMEM_BITS - TB_SHIFT)) - 1;
+
+ get_option(&str, &rand_mem_physical_padding);
+ if (rand_mem_physical_padding < 0)
+ rand_mem_physical_padding = 0;
+ else if (rand_mem_physical_padding > max_padding)
+ rand_mem_physical_padding = max_padding;
+
+ return 0;
+}
+early_param("rand_mem_physical_padding", rand_mem_physical_padding_setup);
+
/* Initialize base and padding for each memory region randomized with KASLR */
void __init kernel_randomize_memory(void)
{
@@ -102,7 +122,7 @@ void __init kernel_randomize_memory(void)
*/
BUG_ON(kaslr_regions[0].base != &page_offset_base);
memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
- CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
+ get_rand_mem_physical_padding();
/* Adapt phyiscal memory region size based on available memory */
if (memory_tb < kaslr_regions[0].size_tb)
--
2.18.0
[PATCH v6 0/3] Add a kernel parameter to change the padding size for KASLR
This patch series are adding an kernel parameter to change the padding size used for KASLR. It is useful for memory hotplug capable system. User can adjust the padding size to use it. It is better if the padding size is calculated automatically, however, ACPI SRAT is not available at the KASLR initialization time. So, I add a message for user to tell the suitable padding size. User can set it on next reboot. This patch series don't change the current default padding size. Change log from v5: - Fix build error if CONFIG_RANDOMIZE_MEMORY is not defined. Change log from v4: - Fix the padding size check (2nd patch) - Add explanation for the parameter in the document. (3rd patch) Change log from v3: - Add a warning message if the padding size for KASLR is not enough. And it says the suitable padding size to user. Change log from v2: - Simplify the description. As Baoquan said, this is similar SGI UV issue, but a little different. Remove SGI UV description. Masayoshi Mizuma (3): x86/mm: Add a kernel parameter to change the padding used for the physical memory mapping ACPI/NUMA: Add warning message if the padding size for KASLR is not enough Documentation/kernel-parameters.txt: Document rand_mem_physical_padding= .../admin-guide/kernel-parameters.txt | 19 arch/x86/include/asm/setup.h | 9 arch/x86/mm/kaslr.c | 22 ++- drivers/acpi/numa.c | 16 ++ 4 files changed, 65 insertions(+), 1 deletion(-) -- 2.18.0
[PATCH v6 2/3] ACPI/NUMA: Add warning message if the padding size for KASLR is not enough
Add warning message if the padding size for KASLR,
rand_mem_physical_padding, is not enough. The message also
says the suitable padding size.
Signed-off-by: Masayoshi Mizuma
---
drivers/acpi/numa.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 8516760..420ed2c 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
static nodemask_t nodes_found_map = NODE_MASK_NONE;
@@ -435,6 +436,7 @@ acpi_table_parse_srat(enum acpi_srat_type id,
int __init acpi_numa_init(void)
{
int cnt = 0;
+ u64 max_possible_phys, max_actual_phys, threshold;
if (acpi_disabled)
return -EINVAL;
@@ -463,6 +465,20 @@ int __init acpi_numa_init(void)
cnt = acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
acpi_parse_memory_affinity, 0);
+
+ /* check the padding size for KASLR is enough. */
+ if (parsed_numa_memblks && kaslr_enabled()) {
+ max_actual_phys = roundup(PFN_PHYS(max_pfn),
+ 1ULL << 40);
+ max_possible_phys = roundup(PFN_PHYS(max_possible_pfn),
+ 1ULL << 40);
+ threshold = max_actual_phys +
+ ((u64)get_rand_mem_physical_padding() << 40);
+
+ if (max_possible_phys > threshold)
+ pr_warn("Set 'rand_mem_physical_padding=%llu'
to avoid memory hotadd failure.\n",
+ (max_possible_phys - max_actual_phys) >> 40);
+ }
}
/* SLIT: System Locality Information Table */
--
2.18.0
Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"
On Tue, 2 Oct 2018 17:15:17 -0700
Daniel Wang wrote:
> On Tue, Oct 2, 2018 at 1:42 AM Petr Mladek wrote:
> >
> > Well, I still wonder why it helped and why you do not see it with 4.4.
> > I have a feeling that the console owner switch helped only by chance.
> > In fact, you might be affected by a race in
> > printk_safe_flush_on_panic() that was fixed by the commit:
> >
> > 554755be08fba31c7 printk: drop in_nmi check from
> > printk_safe_flush_on_panic()
> >
> > The above one commit might be enough. Well, there was one more
> > NMI-related race that was fixed by:
> >
> > ba552399954dde1b printk: Split the code for storing a message into the log
> > buffer
> > a338f84dc196f44b printk: Create helper function to queue deferred console
> > handling
> > 03fc7f9c99c1e7ae printk/nmi: Prevent deadlock when accessing the main log
> > buffer in NMI
>
> All of these commits already exist in 4.14 stable, since 4.14.68. The deadlock
> still exists even when built from 4.14.73 (latest tag) though. And
> cherrypicking
> dbdda842fe96 fixes it.
>
I don't see the big deal of backporting this. The biggest complaints
about backports are from fixes that were added to late -rc releases
where the fixes didn't get much testing. This commit was added in 4.16,
and hasn't had any issues due to the design. Although a fix has been
added:
c14376de3a1 ("printk: Wake klogd when passing console_lock owner")
Also from 4.16, but nothing else according to searching for "Fixes"
tags.
-- Steve
Re: [PATCH v14 1/2] leds: core: Introduce LED pattern trigger
Hi Jacek, On 3 October 2018 at 04:25, Jacek Anaszewski wrote: > Hi Baolin, > > Thank you for the v14. We'll probably need v15, though :-) > > I added the comments in the code below. > > On 10/02/2018 05:43 PM, Baolin Wang wrote: >> This patch adds one new led trigger that LED device can configure >> the software or hardware pattern and trigger it. >> >> Consumers can write 'pattern' file to enable the software pattern >> which alters the brightness for the specified duration with one >> software timer. >> >> Moreover consumers can write 'hw_pattern' file to enable the hardware >> pattern for some LED controllers which can autonomously control >> brightness over time, according to some preprogrammed hardware >> patterns. >> >> Signed-off-by: Raphael Teysseyre >> Signed-off-by: Baolin Wang >> --- >> Changes from v13: >> - Add duration validation for gradual dimming. >> - Coding style optimization. >> >> Changes from v12: >> - Add gradual dimming support for software pattern. >> >> Changes from v11: >> - Change -1 means repeat indefinitely. >> >> Changes from v10: >> - Change 'int' to 'u32' for delta_t field. >> >> Changes from v9: >> - None. >> >> Changes from v8: >> - None. >> >> Changes from v7: >> - Move the SC27XX hardware patterns description into its own ABI file. >> >> Changes from v6: >> - Improve commit message. >> - Optimize the description of the hw_pattern file. >> - Simplify some logics. >> >> Changes from v5: >> - Add one 'hw_pattern' file for hardware patterns. >> >> Changes from v4: >> - Change the repeat file to return the originally written number. >> - Improve comments. >> - Fix some build warnings. >> >> Changes from v3: >> - Reset pattern number to 0 if user provides incorrect pattern string. >> - Support one pattern. >> >> Changes from v2: >> - Remove hardware_pattern boolen. >> - Chnage the pattern string format. >> >> Changes from v1: >> - Use ATTRIBUTE_GROUPS() to define attributes. >> - Introduce hardware_pattern flag to determine if software pattern >> or hardware pattern. >> - Re-implement pattern_trig_store_pattern() function. >> - Remove pattern_get() interface. >> - Improve comments. >> - Other small optimization. >> --- >> .../ABI/testing/sysfs-class-led-trigger-pattern| 76 >> drivers/leds/trigger/Kconfig | 7 + >> drivers/leds/trigger/Makefile | 1 + >> drivers/leds/trigger/ledtrig-pattern.c | 431 >> + >> include/linux/leds.h | 15 + >> 5 files changed, 530 insertions(+) >> create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> create mode 100644 drivers/leds/trigger/ledtrig-pattern.c >> >> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> new file mode 100644 >> index 000..22d7af7 >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> @@ -0,0 +1,76 @@ >> +What:/sys/class/leds//pattern >> +Date:September 2018 >> +KernelVersion: 4.20 >> +Description: >> + Specify a software pattern for the LED, that supports altering >> + the brightness for the specified duration with one software >> + timer. It can do gradual dimming and constant brightness. >> + >> + The pattern is given by a series of tuples, of brightness and >> + duration (ms). The LED is expected to traverse the series and >> + each brightness value for the specified duration. Duration of >> + 0 means brightness should immediately change to new value. >> + >> + 1. When doing gradual dimming, the led brightness will be >> updated >> + every 50 milliseconds, so the duration of each step should not >> + less than 50 milliseconds. > > I'd like to avoid this constraint. Lowest supported delta_t should be 1. > > We should only prevent entering dimming mode if current delta_t > is lower than UPDATE_INTERVAL. I do not think so. If the pattern format is used for dimming and the delta_t is lower than UPDATE_INTERVAL, we should return errors. Since in this case, we can not change to constant mode. Like you mentioned: echo "10 49 20 49" > pattern We can not enter dimming, meanwhile the pattern format is not used for constant brightness, so should return errors for the invalid pattern values. > I also propose to make the dimming interval configurable via sysfs > dimming_interval file. So the dimming_interva range is [1, 50] milliseconds? I am fine with this. Pavel, do you also agree with adding one new file to set the dimming interval or keep it as simple now? > >> The gradual dimming format of the >> + software pattern values should be: >> + "brightness_1 duration_1 brightness_2 duration_2 brightness_3 >> + duration_3 ...". For exampl
Urgent,
Hello Please i still await your response regarding my previous email.
Reminder,
Hello Please i still await your response regarding my previous email.
linux-next: build failure after merge of the vfs tree
Hi Al,
After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
/home/sfr/next/next/fs/f2fs/super.c: In function 'f2fs_remount':
/home/sfr/next/next/fs/f2fs/super.c:1589:16: error: 'MS_RDONLY' undeclared
(first use in this function); did you mean 'IS_RDONLY'?
if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
^
IS_RDONLY
Caused by commit
dcf8001d292b ("vfs: Suppress MS_* flag defs within the kernel unless
explicitly enabled")
interacting with commit
f80f781514ef ("f2fs: checkpoint disabling")
from the f2fs tree.
I have added the following merge fix patch for today. If it is correct,
I assume that it could be applied to f2fs tree as the the other uses of
MS_RDONLY have already been changed to SB_RDONLY. (There is another
use of MS_READONLY in this function that is already cleaned up in the
vfs tree commit.)
From: Stephen Rothwell
Date: Wed, 3 Oct 2018 10:27:04 +1000
Subject: [PATCH] f2fs: update for MS_* flags mostly going away
Signed-off-by: Stephen Rothwell
---
fs/f2fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 6ed77589ff2b..b612a9e4a35e 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1586,7 +1586,7 @@ static int f2fs_remount(struct super_block *sb, int
*flags,
goto restore_opts;
}
- if ((*flags & MS_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
+ if ((*flags & SB_RDONLY) && test_opt(sbi, DISABLE_CHECKPOINT)) {
err = -EINVAL;
f2fs_msg(sbi->sb, KERN_WARNING,
"disabling checkpoint not compatible with read-only");
--
2.18.0
--
Cheers,
Stephen Rothwell
pgpfDneKUFy5e.pgp
Description: OpenPGP digital signature
tracing child threads with address filtering using intel_pt
Hello all,
I am having trouble tracing child threads when using address filtering
with intel_pt ..
Assume this test code:
thread_start(){
...
test();
...
}
test(){
printf("test");
}
main(){
...
pthread_create(.., thread_start,);
}
Tracing the above program with the following command:
perf record -v -m 512,1 -e intel_pt//u -T --switch-events --filter
'filter * @ ./test' -- ./test
Returns zero trace for code executed by child thread, i.e.
thread_start() and test() functions..
While tracing without the filter does include the threads trace:
perf record -v -m 512,1 -e intel_pt//u -T --switch-events -- ./test
Is this intended? or is it a bug?
Thanks!
Mansour.
[PATCH 1/2] ARM: multi_v7_defconfig: enable CONFIG_MMC_UNIPHIER
Enable the UniPhier SD controller driver. Signed-off-by: Masahiro Yamada --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index fc33444..0d56568 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -771,6 +771,7 @@ CONFIG_MMC_ATMELMCI=y CONFIG_MMC_SDHCI_MSM=y CONFIG_MMC_MVSDIO=y CONFIG_MMC_SDHI=y +CONFIG_MMC_UNIPHIER=y CONFIG_MMC_DW=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_ROCKCHIP=y -- 2.7.4
[PATCH 2/2] arm64: defconfig: enable CONFIG_MMC_UNIPHIER
Enable the UniPhier SD controller driver. Signed-off-by: Masahiro Yamada --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index db8d364..a15016e 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -520,6 +520,7 @@ CONFIG_MMC_MESON_GX=y CONFIG_MMC_SDHCI_MSM=y CONFIG_MMC_SPI=y CONFIG_MMC_SDHI=y +CONFIG_MMC_UNIPHIER=y CONFIG_MMC_DW=y CONFIG_MMC_DW_EXYNOS=y CONFIG_MMC_DW_HI3798CV200=y -- 2.7.4
tracing child threads with address filtering using intel_pt pmu
Hello all,
I am having trouble tracing child threads when using address filtering
with intel_pt ..
Assume this test code:
thread_start(){
...
test();
...
}
test(){
printf("test");
}
main(){
...
pthread_create(.., thread_start,);
}
Tracing the above program with the following command:
perf record -v -m 512,1 -e intel_pt//u -T --switch-events --filter
'filter * @ ./test' -- ./test
Returns zero trace for code executed by child thread, i.e.
thread_start() and test() functions..
While tracing without the filter does include the threads trace:
perf record -v -m 512,1 -e intel_pt//u -T --switch-events -- ./test
Is this intended? or is it a bug?
Thanks!
Mansour.
Re: 4.14 backport request for dbdda842fe96f: "printk: Add console owner and waiter logic to load balance console writes"
On Tue, Oct 2, 2018 at 1:42 AM Petr Mladek wrote: > > Well, I still wonder why it helped and why you do not see it with 4.4. > I have a feeling that the console owner switch helped only by chance. > In fact, you might be affected by a race in > printk_safe_flush_on_panic() that was fixed by the commit: > > 554755be08fba31c7 printk: drop in_nmi check from printk_safe_flush_on_panic() > > The above one commit might be enough. Well, there was one more > NMI-related race that was fixed by: > > ba552399954dde1b printk: Split the code for storing a message into the log > buffer > a338f84dc196f44b printk: Create helper function to queue deferred console > handling > 03fc7f9c99c1e7ae printk/nmi: Prevent deadlock when accessing the main log > buffer in NMI All of these commits already exist in 4.14 stable, since 4.14.68. The deadlock still exists even when built from 4.14.73 (latest tag) though. And cherrypicking dbdda842fe96 fixes it. > > Best Regards, > Petr -- Best, Daniel smime.p7s Description: S/MIME Cryptographic Signature
linux-next: manual merge of the vfs tree with the f2fs tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/f2fs/super.c
between commit:
f80f781514ef ("f2fs: checkpoint disabling")
from the f2fs tree and commit:
307c6e5241b4 ("vfs: Require specification of size of mount data for internal
mounts")
from the vfs tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/f2fs/super.c
index 952a67b3184a,89970dd81b0e..
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@@ -1449,53 -1419,8 +1449,54 @@@ static void default_options(struct f2fs
#ifdef CONFIG_QUOTA
static int f2fs_enable_quotas(struct super_block *sb);
#endif
+
+static int f2fs_disable_checkpoint(struct f2fs_sb_info *sbi)
+{
+ struct cp_control cpc;
+ int err;
+
+ sbi->sb->s_flags |= SB_ACTIVE;
+
+ mutex_lock(&sbi->gc_mutex);
+ for (; dirty_segments(sbi) > 2 * NR_CURSEG_TYPE;) {
+ err = f2fs_gc(sbi, true, false, NULL_SEGNO);
+ if (err == -ENODATA)
+ break;
+ if (err && err != -EAGAIN) {
+ mutex_unlock(&sbi->gc_mutex);
+ return err;
+ }
+ }
+ mutex_unlock(&sbi->gc_mutex);
+
+ err = sync_filesystem(sbi->sb);
+ if (err)
+ return err;
+
+ mutex_lock(&sbi->gc_mutex);
+ cpc.reason = CP_PAUSE;
+ set_sbi_flag(sbi, SBI_CP_DISABLED);
+ f2fs_write_checkpoint(sbi, &cpc);
+
+ sbi->unusable_block_count = 0;
+ mutex_unlock(&sbi->gc_mutex);
+ return 0;
+}
+
+static void f2fs_enable_checkpoint(struct f2fs_sb_info *sbi)
+{
+ mutex_lock(&sbi->gc_mutex);
+ f2fs_dirty_to_prefree(sbi);
+
+ clear_sbi_flag(sbi, SBI_CP_DISABLED);
+ set_sbi_flag(sbi, SBI_IS_DIRTY);
+ mutex_unlock(&sbi->gc_mutex);
+
+ f2fs_sync_fs(sbi->sb, 1);
+}
+
- static int f2fs_remount(struct super_block *sb, int *flags, char *data)
+ static int f2fs_remount(struct super_block *sb, int *flags,
+ char *data, size_t data_size)
{
struct f2fs_sb_info *sbi = F2FS_SB(sb);
struct f2fs_mount_info org_mount_opt;
pgpcyPrVQL3on.pgp
Description: OpenPGP digital signature
Re: [PATCH] [v3] HID: add support for Apple Magic Trackpad 2
On Tue, Oct 02, 2018 at 03:39:31PM -0700, Sean O'Brien wrote:
> On Mon, Oct 1, 2018 at 1:43 AM Benjamin Tissoires
> wrote:
> >
> > [adding Peter, for the libinput question]
> >
> > On Fri, Sep 21, 2018 at 1:13 AM Sean O'Brien wrote:
> > >
> > > USB device
> > > Vendor 05ac (Apple)
> > > Device 0265 (Magic Trackpad 2)
> > > Bluetooth device
> > > Vendor 004c (Apple)
> > > Device 0265 (Magic Trackpad 2)
> > >
> > > Add support for Apple Magic Trackpad 2 over USB and bluetooth, putting
> > > the device in multi-touch mode.
> > >
> > > Signed-off-by: Claudio Mettler
> > > Signed-off-by: Marek Wyborski
> > > Signed-off-by: Sean O'Brien
> > > ---
> > >
> >
> > a few nitpcks:
> >
> > > drivers/hid/hid-ids.h| 1 +
> > > drivers/hid/hid-magicmouse.c | 149 +++
> > > 2 files changed, 134 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> > > index 5146ee029db4..bb0cd212c7cc 100644
> > > --- a/drivers/hid/hid-ids.h
> > > +++ b/drivers/hid/hid-ids.h
> > > @@ -92,6 +92,7 @@
> > > #define USB_DEVICE_ID_APPLE_MIGHTYMOUSE0x0304
> > > #define USB_DEVICE_ID_APPLE_MAGICMOUSE 0x030d
> > > #define USB_DEVICE_ID_APPLE_MAGICTRACKPAD 0x030e
> > > +#define USB_DEVICE_ID_APPLE_MAGICTRACKPAD2 0x0265
> > > #define USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI 0x020e
> > > #define USB_DEVICE_ID_APPLE_FOUNTAIN_ISO 0x020f
> > > #define USB_DEVICE_ID_APPLE_GEYSER_ANSI0x0214
> > > diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
> > > index b454c4386157..6a3a6c83e509 100644
> > > --- a/drivers/hid/hid-magicmouse.c
> > > +++ b/drivers/hid/hid-magicmouse.c
> > > @@ -54,6 +54,8 @@ module_param(report_undeciphered, bool, 0644);
> > > MODULE_PARM_DESC(report_undeciphered, "Report undeciphered multi-touch
> > > state field using a MSC_RAW event");
> > >
> > > #define TRACKPAD_REPORT_ID 0x28
> > > +#define TRACKPAD2_USB_REPORT_ID 0x02
> > > +#define TRACKPAD2_BT_REPORT_ID 0x31
> > > #define MOUSE_REPORT_ID0x29
> > > #define DOUBLE_REPORT_ID 0xf7
> > > /* These definitions are not precise, but they're close enough. (Bits
> > > @@ -91,6 +93,17 @@ MODULE_PARM_DESC(report_undeciphered, "Report
> > > undeciphered multi-touch state fie
> > > #define TRACKPAD_RES_Y \
> > > ((TRACKPAD_MAX_Y - TRACKPAD_MIN_Y) / (TRACKPAD_DIMENSION_Y / 100))
> > >
> > > +#define TRACKPAD2_DIMENSION_X (float)16000
> > > +#define TRACKPAD2_MIN_X -3678
> > > +#define TRACKPAD2_MAX_X 3934
> > > +#define TRACKPAD2_RES_X \
> > > + ((TRACKPAD2_MAX_X - TRACKPAD2_MIN_X) / (TRACKPAD2_DIMENSION_X /
> > > 100))
> > > +#define TRACKPAD2_DIMENSION_Y (float)11490
> > > +#define TRACKPAD2_MIN_Y -2478
> > > +#define TRACKPAD2_MAX_Y 2587
> > > +#define TRACKPAD2_RES_Y \
> > > + ((TRACKPAD2_MAX_Y - TRACKPAD2_MIN_Y) / (TRACKPAD2_DIMENSION_Y /
> > > 100))
> > > +
> > > /**
> > > * struct magicmouse_sc - Tracks Magic Mouse-specific data.
> > > * @input: Input device through which we report events.
> > > @@ -183,6 +196,7 @@ static void magicmouse_emit_touch(struct
> > > magicmouse_sc *msc, int raw_id, u8 *tda
> > > {
> > > struct input_dev *input = msc->input;
> > > int id, x, y, size, orientation, touch_major, touch_minor, state,
> > > down;
> > > + int pressure = 0;
> > >
> > > if (input->id.product == USB_DEVICE_ID_APPLE_MAGICMOUSE) {
> > > id = (tdata[6] << 2 | tdata[5] >> 6) & 0xf;
> > > @@ -194,6 +208,20 @@ static void magicmouse_emit_touch(struct
> > > magicmouse_sc *msc, int raw_id, u8 *tda
> > > touch_minor = tdata[4];
> > > state = tdata[7] & TOUCH_STATE_MASK;
> > > down = state != TOUCH_STATE_NONE;
> > > + } else if (input->id.product ==
> > > USB_DEVICE_ID_APPLE_MAGICTRACKPAD2) {
> > > + id = tdata[8] & 0xf;
> > > + x = (tdata[1] << 27 | tdata[0] << 19) >> 19;
> > > + y = -((tdata[3] << 30 | tdata[2] << 22 | tdata[1] << 14)
> > > >> 19);
> > > + size = tdata[6];
> > > + orientation = (tdata[8] >> 5) - 4;
> > > + touch_major = tdata[4];
> > > + touch_minor = tdata[5];
> > > + /* Add to pressure to prevent libraries such as libinput
> > > +* from ignoring low pressure touches
> > > +*/
> > > + pressure = tdata[7] + 30;
> >
> > Peter, can you have a look?
> >
> > To me, while adding this threshold, you are basically fooling
> > userspace, and we might want to come back to the raw values at some
> > point.
> > If there is a userspace problem, it has to be solved in userspace.
> >
>
> I'm fine with removing the offset. I haven't personally tested using
> libinput, but the chromium OS gesture detector I've been using can
> handle pressure values of 0.
libinput uses touch major/minor but only if a thres
[PATCH] fat: Expand a slightly out-of-date comment
The file namei.c seems to have been renamed to namei_msdos.c, so I decided to update the comment with the correct name, and expand it a bit to tell the reader what to look for. Signed-off-by: Mihir Mehta --- fs/fat/dir.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/fat/dir.c b/fs/fat/dir.c index 7f5f369..ce5f958 100644 --- a/fs/fat/dir.c +++ b/fs/fat/dir.c @@ -369,7 +369,9 @@ static int fat_parse_short(struct super_block *sb, } memcpy(work, de->name, sizeof(work)); - /* see namei.c, msdos_format_name */ + /* For an explanation of the special treatment of 0x05 in +* filenames, see msdos_format_name in namei_msdos.c +*/ if (work[0] == 0x05) work[0] = 0xE5; -- 2.7.4
[GIT PULL] ARM: dts: uniphier: UniPhier DT updates for v4.20
Hi Arnd, Olof, Please pull UniPhier DT updates for the v4.20 MW. In this cycle, I queued up all arm/arm64 changes into a single branch to avoid build errors. Thanks! The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git tags/uniphier-dt-v4.20 for you to fetch changes up to 84a9c4d55907feece68c6012d3c030cf5c841ceb: arm64: dts: uniphier: add SD controller nodes (2018-10-03 08:21:27 +0900) UniPhier ARM SoC DT updates for v4.20 - Add more clocks to NAND controller nodes - Add SPI controller nodes - Add SD controller nodes Kunihiko Hayashi (3): ARM: dts: uniphier: add SPI pin-mux node ARM: dts: uniphier: add SPI node for UniPhier 32bit SoCs arm64: dts: uniphier: add SPI node for LD20, LD11 and PXs3 Masahiro Yamada (4): ARM: uniphier: dts: add more clocks to Denali NAND controller node arm64: uniphier: dts: add more clocks to Denali NAND controller node ARM: dts: uniphier: add SD/eMMC controller nodes arm64: dts: uniphier: add SD controller nodes arch/arm/boot/dts/uniphier-ld4-ref.dts| 4 ++ arch/arm/boot/dts/uniphier-ld4.dtsi | 48 ++- arch/arm/boot/dts/uniphier-ld6b-ref.dts | 4 ++ arch/arm/boot/dts/uniphier-pinctrl.dtsi | 25 arch/arm/boot/dts/uniphier-pro4-ace.dts | 4 ++ arch/arm/boot/dts/uniphier-pro4-ref.dts | 4 ++ arch/arm/boot/dts/uniphier-pro4-sanji.dts | 4 ++ arch/arm/boot/dts/uniphier-pro4.dtsi | 62 +++- arch/arm/boot/dts/uniphier-pro5.dtsi | 59 ++- arch/arm/boot/dts/uniphier-pxs2-gentil.dts| 4 ++ arch/arm/boot/dts/uniphier-pxs2-vodka.dts | 4 ++ arch/arm/boot/dts/uniphier-pxs2.dtsi | 59 ++- arch/arm/boot/dts/uniphier-sld8-ref.dts | 4 ++ arch/arm/boot/dts/uniphier-sld8.dtsi | 48 ++- arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 25 +++- arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 61 ++- .../boot/dts/socionext/uniphier-pxs3-ref.dts | 4 ++ arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi | 43 +- 18 files changed, 458 insertions(+), 8 deletions(-) -- Best Regards Masahiro Yamada
Re: [PATCH v2] perf: xgene: Add CPU hotplug support
Hi Mark, > On Oct 2, 2018, at 4:46 AM, Mark Rutland wrote: > > [NOTICE: This email originated from an external sender. Please be mindful of > safe email handling and proprietary information protection practices.] > > > Hi Hoan, > > On Wed, Sep 19, 2018 at 06:44:30PM +, Hoan Tran wrote: >> This patch adds CPU hotplug support where the PMU migrates the context to >> another online CPU when its CPU is offline. >> >> It fixes the below issue where the user does offline the CPU which is >> assigned >> to this PMU. >> >> Assuming, CPU0 is assigned for this PMU. When the user does offline CPU0 >> [root@(none) ~]# echo 0 > /sys/devices/system/cpu/cpu0/online >> This PMU does not work anymore and shows the below error. >> [root@(none) ~]# perf stat -a -e l3c0/cycle-count/,l3c0/write/ sleep 1 >> Error: >> The sys_perf_event_open() syscall returned with 19 (No such device) for >> event (l3c0/cycle-count/). >> /bin/dmesg may provide additional information. >> No CONFIG_PERF_EVENTS=y kernel support configured? >> >> With this patch, when CPU0 is offline, PMU migrates to another online CPU and >> works on that CPU. >> >> Signed-off-by: Hoan Tran >> --- >> v2: >> * Remove the cpuhp instance when unregistering the PMU > > Unfortunately, this has come through whitespae-damaged, with a > disclaimer in the footer. > > Could you please resend with those two details fixed? I’ll fix it and send you another version later. Thanks and Regards Hoan > > Thanks, > Mark.
Sparse warnings from calls to max3() and max
Hi, Sparse has suddenly started issuing as many as 11 warnings of "expression using sizeof(void)" for each call to max3(). There are similar warnings for calls to max(), thus I think this is the origin of the problem. My sparse version is 20180324-1.3-x86_64 installed in openSUSE Tumbleweed. My kernel is 4.19.0-rc6. Thanks, Larry
Re: [RFC PATCH 03/10] arch/x86: Re-arrange RDT init code
Hi Reinette,
Thanks for the review. My response below.
On 10/02/2018 02:21 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 9/24/2018 12:19 PM, Moger, Babu wrote:
>> Re-organize the RDT init code. Separate the call sequence for each
>> feature. That way, it is easy to call quirks or features separately
>> for each vendor if there are differences.
>>
>> Signed-off-by: Babu Moger
>> ---
>> arch/x86/kernel/cpu/rdt.c | 44 ---
>> 1 file changed, 32 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/rdt.c b/arch/x86/kernel/cpu/rdt.c
>> index b361c63170d7..736715b81fd8 100644
>> --- a/arch/x86/kernel/cpu/rdt.c
>> +++ b/arch/x86/kernel/cpu/rdt.c
>> @@ -813,10 +813,6 @@ static __init bool get_rdt_alloc_resources(void)
>> ret = true;
>> }
>>
>> -if (rdt_cpu_has(X86_FEATURE_MBA)) {
>> -if (rdt_get_mem_config(&rdt_resources_all[RDT_RESOURCE_MBA]))
>> -ret = true;
>> -}
>
> The commit message mentions that the call sequence for each feature is
> separated, but here only the MBA feature is separated.
Yes. MBA and quirks are separated. I will fix the commit message. I
overlooked some of the errors returned by these functions. Let me go back
and update this patch. Will keep mostly as is. Only separate MBA and
quirks which are important. Will make sure errors are propagated properly.
>
> The MBA feature detection is removed above (more later)
>
>> return ret;
>> }
>>
>> @@ -831,11 +827,12 @@ static __init bool get_rdt_mon_resources(void)
>>
>> if (!rdt_mon_features)
>> return false;
>> +else
>> +return true;
>>
>> -return !rdt_get_mon_l3_config(&rdt_resources_all[RDT_RESOURCE_L3]);
>> }
>>
>> -static __init void rdt_quirks(void)
>> +static __init void rdt_quirks_intel(void)
>> {
>> switch (boot_cpu_data.x86_model) {
>> case INTEL_FAM6_HASWELL_X:
>> @@ -850,13 +847,22 @@ static __init void rdt_quirks(void)
>> }
>> }
>>
>> -static __init bool get_rdt_resources(void)
>> +static __init void rdt_quirks(void)
>> {
>> -rdt_quirks();
>> -rdt_alloc_capable = get_rdt_alloc_resources();
>> -rdt_mon_capable = get_rdt_mon_resources();
>> +if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
>> +rdt_quirks_intel();
>> +}
>> +
>> +static __init void rdt_detect_l3_mon(void)
>> +{
>> +if (rdt_mon_capable)
>> +rdt_get_mon_l3_config(&rdt_resources_all[RDT_RESOURCE_L3]);
>
> The possible errors from this configuration is now lost.
Yes. I overlooked it. Same comment as above. Let me go back and update
this patch.
>
>> +}
>>
>> -return (rdt_mon_capable || rdt_alloc_capable);
>> +static __init void rdt_check_mba(void)
>> +{
>> +if (rdt_cpu_has(X86_FEATURE_MBA))
>> +rdt_get_mem_config(&rdt_resources_all[RDT_RESOURCE_MBA]);
>
> Here too the possible failure of this configuration is now lost.
Ditto.. Let me go back and update this patch.
>
>> }
>>
>> static enum cpuhp_state rdt_online;
>> @@ -866,8 +872,22 @@ static int __init rdt_late_init(void)
>> struct rdt_resource *r;
>> int state, ret;
>>
>> -if (!get_rdt_resources())
>> +/* Run quirks first */
>> +rdt_quirks();
>> +
>> +rdt_alloc_capable = get_rdt_alloc_resources();
>> +rdt_mon_capable = get_rdt_mon_resources();
>> +
>> +if (!(rdt_alloc_capable || rdt_mon_capable)) {
>> +pr_info("RDT allocation or monitoring not detected\n");
>
> This function ends with a log entry for every resource discovered. Is
> this new log entry needed to indicate that such resources have not been
> found? Could it not just be the absence of the other message?
As this is relatively new feature, so I added this info message. It helped
me debug what went wrong. Otherwise, I don't see anything. I can remove it
if the message is too annoying to the user.
>
>> return -ENODEV;
>> +}
>
> ... (continued from above) ... since the MBA feature detection was
> removed from get_rdt_alloc_resources() would the above not cause failure
> on systems that only support MBA?
yes. Let me go back and update this patch.
>
>> +
>> +/* Detect l3 monitoring resources */
>
> I do not think this comment is accurate ... has the monitoring resources
> not been detected earlier in get_rdt_mon_resources() and now they will
> be configured?
>
>> +rdt_detect_l3_mon();
>> +
>> +/* Check for Memory Bandwidth Allocation */
>> +rdt_check_mba();
>
> To follow up on above .. the potential failure of these configurations
> are now lost here. Initialization should not continue if these
> configurations failed.
Yes. Let me go back and update this patch.
>
>>
>> rdt_init_padding();
>>
>>
>
> Reinette
>
Re: general protection fault in rb_erase
On Tue, Sep 25, 2018 at 04:44:03PM -0700, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:846e8dd47c26 Merge tag 'scsi-fixes' of git://git.kernel.or.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=15c874a140 > kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f > dashboard link: https://syzkaller.appspot.com/bug?extid=e81ccd4744c6c4f71354 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15bddd2a40 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1293d3fa40 Fixed with this patch: http://patchwork.ozlabs.org/patch/978083/
[PATCH 6/6] Staging: rts5208: xd.c: Fixed all braces issues of the file
Fixed all the braces issues of the xd.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/xd.c | 232 ++-
1 file changed, 92 insertions(+), 140 deletions(-)
diff --git a/drivers/staging/rts5208/xd.c b/drivers/staging/rts5208/xd.c
index 261d868a3072..415fea2f9ff1 100644
--- a/drivers/staging/rts5208/xd.c
+++ b/drivers/staging/rts5208/xd.c
@@ -60,9 +60,8 @@ static int xd_set_init_para(struct rtsx_chip *chip)
xd_card->xd_clock = CLK_50;
retval = switch_clock(chip, xd_card->xd_clock);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -73,14 +72,12 @@ static int xd_switch_clock(struct rtsx_chip *chip)
int retval;
retval = select_card(chip, XD_CARD);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
retval = switch_clock(chip, xd_card->xd_clock);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -102,9 +99,8 @@ static int xd_read_id(struct rtsx_chip *chip, u8 id_cmd, u8
*id_buf, u8 buf_len)
rtsx_add_cmd(chip, READ_REG_CMD, (u16)(XD_ADDRESS1 + i), 0, 0);
retval = rtsx_send_cmd(chip, XD_CARD, 20);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_FAIL;
- }
ptr = rtsx_get_cmd_data(chip) + 1;
if (id_buf && buf_len) {
@@ -173,9 +169,8 @@ static int xd_read_redundant(struct rtsx_chip *chip, u32
page_addr,
rtsx_add_cmd(chip, READ_REG_CMD, XD_PARITY, 0, 0);
retval = rtsx_send_cmd(chip, XD_CARD, 500);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_FAIL;
- }
if (buf && buf_len) {
u8 *ptr = rtsx_get_cmd_data(chip) + 1;
@@ -193,9 +188,8 @@ static int xd_read_data_from_ppb(struct rtsx_chip *chip,
int offset,
{
int retval, i;
- if (!buf || (buf_len < 0)) {
+ if (!buf || (buf_len < 0))
return STATUS_FAIL;
- }
rtsx_init_cmd(chip);
@@ -220,9 +214,8 @@ static int xd_read_cis(struct rtsx_chip *chip, u32
page_addr, u8 *buf,
int retval;
u8 reg;
- if (!buf || (buf_len < 10)) {
+ if (!buf || (buf_len < 10))
return STATUS_FAIL;
- }
rtsx_init_cmd(chip);
@@ -246,36 +239,35 @@ static int xd_read_cis(struct rtsx_chip *chip, u32
page_addr, u8 *buf,
}
retval = rtsx_read_register(chip, XD_PAGE_STATUS, ®);
- if (retval) {
+ if (retval)
return retval;
- }
+
if (reg != XD_GPG) {
rtsx_clear_xd_error(chip);
return STATUS_FAIL;
}
retval = rtsx_read_register(chip, XD_CTL, ®);
- if (retval) {
+ if (retval)
return retval;
- }
+
if (!(reg & XD_ECC1_ERROR) || !(reg & XD_ECC1_UNCORRECTABLE)) {
retval = xd_read_data_from_ppb(chip, 0, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
+
if (reg & XD_ECC1_ERROR) {
u8 ecc_bit, ecc_byte;
retval = rtsx_read_register(chip, XD_ECC_BIT1,
&ecc_bit);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_read_register(chip, XD_ECC_BYTE1,
&ecc_byte);
- if (retval) {
+ if (retval)
return retval;
- }
dev_dbg(rtsx_dev(chip), "ECC_BIT1 = 0x%x, ECC_BYTE1 =
0x%x\n",
ecc_bit, ecc_byte);
@@ -291,22 +283,21 @@ static int xd_read_cis(struct rtsx_chip *chip, u32
page_addr, u8 *buf,
rtsx_clear_xd_error(chip);
retval = xd_read_data_from_ppb(chip, 256, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
+
if (reg & XD_ECC2_ERROR) {
u8 ecc_bit, ecc_byte;
retval = rtsx_read_register(chip, XD_ECC_BIT2,
&ecc_bit);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_read_register(chip, XD_ECC_BYTE2,
[PATCH 5/6] Staging: rts5208: spi.c: Fixed all braces issues of the file
Fixed all the braces issues of the spi.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/spi.c | 153 +-
1 file changed, 59 insertions(+), 94 deletions(-)
diff --git a/drivers/staging/rts5208/spi.c b/drivers/staging/rts5208/spi.c
index 4675668ad977..420264bc03e5 100644
--- a/drivers/staging/rts5208/spi.c
+++ b/drivers/staging/rts5208/spi.c
@@ -41,14 +41,13 @@ static int spi_init(struct rtsx_chip *chip)
retval = rtsx_write_register(chip, SPI_CONTROL, 0xFF,
CS_POLARITY_LOW | DTO_MSB_FIRST
| SPI_MASTER | SPI_MODE0 | SPI_AUTO);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SPI_TCTL, EDO_TIMING_MASK,
SAMPLE_DELAY_HALF);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -60,42 +59,37 @@ static int spi_set_init_para(struct rtsx_chip *chip)
retval = rtsx_write_register(chip, SPI_CLK_DIVIDER1, 0xFF,
(u8)(spi->clk_div >> 8));
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SPI_CLK_DIVIDER0, 0xFF,
(u8)(spi->clk_div));
- if (retval) {
+ if (retval)
return retval;
- }
retval = switch_clock(chip, spi->spi_clock);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
retval = select_card(chip, SPI_CARD);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
retval = rtsx_write_register(chip, CARD_CLK_EN, SPI_CLK_EN,
SPI_CLK_EN);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, CARD_OE, SPI_OUTPUT_EN,
SPI_OUTPUT_EN);
- if (retval) {
+ if (retval)
return retval;
- }
wait_timeout(10);
retval = spi_init(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -247,47 +241,45 @@ static int spi_init_eeprom(struct rtsx_chip *chip)
clk = CLK_30;
retval = rtsx_write_register(chip, SPI_CLK_DIVIDER1, 0xFF, 0x00);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SPI_CLK_DIVIDER0, 0xFF, 0x27);
- if (retval) {
+ if (retval)
return retval;
- }
retval = switch_clock(chip, clk);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
+
retval = select_card(chip, SPI_CARD);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
+
retval = rtsx_write_register(chip, CARD_CLK_EN, SPI_CLK_EN,
SPI_CLK_EN);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, CARD_OE, SPI_OUTPUT_EN,
SPI_OUTPUT_EN);
- if (retval) {
+ if (retval)
return retval;
- }
+
wait_timeout(10);
retval = rtsx_write_register(chip, SPI_CONTROL, 0xFF,
CS_POLARITY_HIGH | SPI_EEPROM_AUTO);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SPI_TCTL, EDO_TIMING_MASK,
SAMPLE_DELAY_HALF);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -306,9 +298,8 @@ static int spi_eeprom_program_enable(struct rtsx_chip *chip)
SPI_TRANSFER0_END);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -318,14 +309,12 @@ int spi_erase_eeprom_chip(struct rtsx_chip *chip)
int retval;
retval = spi_init_eeprom(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
retval = spi_eeprom_program_enable(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
rtsx_init_cmd(chip);
@@ -339,14 +328,12 @@ int spi_erase_eeprom_chip(struct rtsx_chip *chip)
[PATCH 3/6] Staging: rts5208: rtsx_scsi.c: Fixed all braces issues of the file
Fixed all the braces issues of the rtsx_scsi.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_scsi.c | 108 ++--
1 file changed, 36 insertions(+), 72 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_scsi.c
b/drivers/staging/rts5208/rtsx_scsi.c
index c9a6d97938f6..9c594a778425 100644
--- a/drivers/staging/rts5208/rtsx_scsi.c
+++ b/drivers/staging/rts5208/rtsx_scsi.c
@@ -507,9 +507,8 @@ static int inquiry(struct scsi_cmnd *srb, struct rtsx_chip
*chip)
}
buf = vmalloc(scsi_bufflen(srb));
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
#ifdef SUPPORT_MAGIC_GATE
if ((chip->mspro_formatter_enable) &&
@@ -637,9 +636,8 @@ static int request_sense(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = vmalloc(scsi_bufflen(srb));
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
tmp = (unsigned char *)sense;
memcpy(buf, tmp, scsi_bufflen(srb));
@@ -783,9 +781,8 @@ static int mode_sense(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
#endif
buf = kmalloc(data_size, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
page_code = srb->cmnd[2] & 0x3f;
@@ -999,9 +996,8 @@ static int read_format_capacity(struct scsi_cmnd *srb,
struct rtsx_chip *chip)
buf_len = (scsi_bufflen(srb) > 12) ? 0x14 : 12;
buf = kmalloc(buf_len, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
buf[i++] = 0;
buf[i++] = 0;
@@ -1076,9 +1072,8 @@ static int read_capacity(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = kmalloc(8, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
card_size = get_card_size(chip, lun);
buf[0] = (unsigned char)((card_size - 1) >> 24);
@@ -1116,9 +,8 @@ static int read_eeprom(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = ((u16)srb->cmnd[4] << 8) | srb->cmnd[5];
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
retval = rtsx_force_power_on(chip, SSC_PDCTL);
if (retval != STATUS_SUCCESS) {
@@ -1180,9 +1174,8 @@ static int write_eeprom(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = (unsigned short)min_t(unsigned int, scsi_bufflen(srb),
len);
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
rtsx_stor_get_xfer_buf(buf, len, srb);
scsi_set_resid(srb, scsi_bufflen(srb) - len);
@@ -1227,9 +1220,8 @@ static int read_mem(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
retval = rtsx_force_power_on(chip, SSC_PDCTL);
if (retval != STATUS_SUCCESS) {
@@ -1282,9 +1274,8 @@ static int write_mem(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = (unsigned short)min_t(unsigned int, scsi_bufflen(srb), len);
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
rtsx_stor_get_xfer_buf(buf, len, srb);
scsi_set_resid(srb, scsi_bufflen(srb) - len);
@@ -1702,41 +1693,35 @@ static int set_chip_mode(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
if (phy_debug_mode) {
chip->phy_debug_mode = 1;
retval = rtsx_write_register(chip, CDRESUMECTL, 0x77, 0);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
rtsx_disable_bus_int(chip);
retval = rtsx_read_phy_register(chip, 0x1C, ®);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
reg |= 0x0001;
retval = rtsx_write_phy_register(chip, 0x1C, reg);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
} else {
chip->phy_debug_mode = 0;
retval = rtsx_write_register(chip, CDRESUMECTL, 0x77, 0x77);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
rtsx_enable_bus_int(chip);
retval = rtsx_read_phy_register(chip, 0x1C, ®);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
[PATCH 4/6] Staging: rts5208: sd.c: Fixed all braces issues of the file
Fixed all the braces issues of the sd.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/sd.c | 704 +--
1 file changed, 268 insertions(+), 436 deletions(-)
diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index e7efa34195c7..930c61ccb047 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -109,9 +109,8 @@ static int sd_check_data0_status(struct rtsx_chip *chip)
u8 stat;
retval = rtsx_read_register(chip, REG_SD_STAT1, &stat);
- if (retval) {
+ if (retval)
return retval;
- }
if (!(stat & SD_DAT0_STATUS)) {
sd_set_err_code(chip, SD_BUSY);
@@ -234,9 +233,8 @@ static int sd_send_cmd_get_rsp(struct rtsx_chip *chip, u8
cmd_idx,
if ((cmd_idx != SEND_RELATIVE_ADDR) &&
(cmd_idx != SEND_IF_COND)) {
if (cmd_idx != STOP_TRANSMISSION) {
- if (ptr[1] & 0x80) {
+ if (ptr[1] & 0x80)
return STATUS_FAIL;
- }
}
#ifdef SUPPORT_SD_LOCK
if (ptr[1] & 0x7D) {
@@ -284,9 +282,8 @@ static int sd_read_data(struct rtsx_chip *chip,
if (!buf)
buf_len = 0;
- if (buf_len > 512) {
+ if (buf_len > 512)
return STATUS_FAIL;
- }
rtsx_init_cmd(chip);
@@ -331,9 +328,8 @@ static int sd_read_data(struct rtsx_chip *chip,
if (buf && buf_len) {
retval = rtsx_read_ppbuf(chip, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
}
return STATUS_SUCCESS;
@@ -359,9 +355,8 @@ static int sd_write_data(struct rtsx_chip *chip, u8
trans_mode,
if (buf && buf_len) {
retval = rtsx_write_ppbuf(chip, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
}
rtsx_init_cmd(chip);
@@ -426,9 +421,8 @@ static int sd_check_csd(struct rtsx_chip *chip, char
check_wp)
break;
}
- if (i == 6) {
+ if (i == 6)
return STATUS_FAIL;
- }
memcpy(sd_card->raw_csd, rsp + 1, 15);
@@ -543,9 +537,8 @@ static int sd_set_sample_push_timing(struct rtsx_chip *chip)
}
retval = rtsx_write_register(chip, REG_SD_CFG1, 0x1C, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -606,9 +599,8 @@ static int sd_set_clock_divider(struct rtsx_chip *chip, u8
clk_div)
val = 0x20;
retval = rtsx_write_register(chip, REG_SD_CFG1, mask, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -619,16 +611,14 @@ static int sd_set_init_para(struct rtsx_chip *chip)
int retval;
retval = sd_set_sample_push_timing(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
sd_choose_proper_clock(chip);
retval = switch_clock(chip, sd_card->sd_clock);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -651,9 +641,8 @@ int sd_select_card(struct rtsx_chip *chip, int select)
}
retval = sd_send_cmd_get_rsp(chip, cmd_idx, addr, cmd_type, NULL, 0);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -667,9 +656,8 @@ static int sd_update_lock_status(struct rtsx_chip *chip)
retval = sd_send_cmd_get_rsp(chip, SEND_STATUS, sd_card->sd_addr,
SD_RSP_TYPE_R1, rsp, 5);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
if (rsp[1] & 0x02)
sd_card->sd_lock_status |= SD_LOCKED;
@@ -679,9 +667,8 @@ static int sd_update_lock_status(struct rtsx_chip *chip)
dev_dbg(rtsx_dev(chip), "sd_card->sd_lock_status = 0x%x\n",
sd_card->sd_lock_status);
- if (rsp[1] & 0x01) {
+ if (rsp[1] & 0x01)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -698,9 +685,8 @@ static int sd_wait_state_data_ready(struct rtsx_chip *chip,
u8 state,
retval = sd_send_cmd_get_rsp(chip, SEND_STATUS,
sd_card->sd_addr, SD_RSP_TYPE_R1,
rsp, 5
[PATCH 2/6] Staging: rts5208: rtsx_chip.c: Fixed all braces issues of the file
Fixed all the braces issues of the rtsx_chip.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_chip.c | 463
1 file changed, 199 insertions(+), 264 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_chip.c
b/drivers/staging/rts5208/rtsx_chip.c
index 6b1234bff09c..6bec2ddc75f2 100644
--- a/drivers/staging/rts5208/rtsx_chip.c
+++ b/drivers/staging/rts5208/rtsx_chip.c
@@ -116,34 +116,31 @@ static int rtsx_pre_handle_sdio_old(struct rtsx_chip
*chip)
0xFF,
MS_INS_PU | SD_WP_PU |
SD_CD_PU | SD_CMD_PU);
- if (retval) {
+ if (retval)
return retval;
- }
+
} else {
retval = rtsx_write_register(chip, FPGA_PULL_CTL,
0xFF,
FPGA_SD_PULL_CTL_EN);
- if (retval) {
+ if (retval)
return retval;
- }
+
}
retval = rtsx_write_register(chip, CARD_SHARE_MODE, 0xFF,
CARD_SHARE_48_SD);
- if (retval) {
+ if (retval)
return retval;
- }
/* Enable SDIO internal clock */
retval = rtsx_write_register(chip, 0xFF2C, 0x01, 0x01);
- if (retval) {
+ if (retval)
return retval;
- }
retval = rtsx_write_register(chip, SDIO_CTRL, 0xFF,
SDIO_BUS_CTRL | SDIO_CD_CTRL);
- if (retval) {
+ if (retval)
return retval;
- }
chip->sd_int = 1;
chip->sd_io = 1;
@@ -164,16 +161,16 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (chip->driver_first_load) {
if (CHECK_PID(chip, 0x5288)) {
retval = rtsx_read_register(chip, 0xFE5A, &tmp);
- if (retval) {
+ if (retval)
return retval;
- }
+
if (tmp & 0x08)
sw_bypass_sd = true;
} else if (CHECK_PID(chip, 0x5208)) {
retval = rtsx_read_register(chip, 0xFE70, &tmp);
- if (retval) {
+ if (retval)
return retval;
- }
+
if (tmp & 0x80)
sw_bypass_sd = true;
}
@@ -192,9 +189,9 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip *chip)
u8 cd_toggle_mask = 0;
retval = rtsx_read_register(chip, TLPTISTAT, &tmp);
- if (retval) {
+ if (retval)
return retval;
- }
+
cd_toggle_mask = 0x08;
if (tmp & cd_toggle_mask) {
@@ -202,22 +199,20 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (CHECK_PID(chip, 0x5288)) {
retval = rtsx_write_register(chip, 0xFE5A,
0x08, 0x00);
- if (retval) {
+ if (retval)
return retval;
- }
+
} else if (CHECK_PID(chip, 0x5208)) {
retval = rtsx_write_register(chip, 0xFE70,
0x80, 0x00);
- if (retval) {
+ if (retval)
return retval;
- }
}
retval = rtsx_write_register(chip, TLPTISTAT, 0xFF,
tmp);
- if (retval) {
+ if (retval)
return retval;
- }
chip->need_reset |= SD_CARD;
} else {
@@ -225,36 +220,35 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (chip->asic_code) {
retval = sd_pull_ctl_enable(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-
[PATCH 1/6] Staging: rts5208: rtsx_card.c: Fixed all braces issues of the file
Fixed all the braces issues of the rtsx_card.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_card.c | 96 +++--
1 file changed, 37 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_card.c
b/drivers/staging/rts5208/rtsx_card.c
index d26a8e372fce..b45abbe29bc2 100644
--- a/drivers/staging/rts5208/rtsx_card.c
+++ b/drivers/staging/rts5208/rtsx_card.c
@@ -647,9 +647,8 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
dev_dbg(rtsx_dev(chip), "Switch SSC clock to %dMHz (cur_clk = %d)\n",
clk, chip->cur_clk);
- if ((clk <= 2) || (n > max_n)) {
+ if ((clk <= 2) || (n > max_n))
return STATUS_FAIL;
- }
mcu_cnt = (u8)(125 / clk + 3);
if (mcu_cnt > 7)
@@ -688,15 +687,13 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_send_cmd(chip, 0, WAIT_TIME);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_ERROR;
- }
udelay(10);
retval = rtsx_write_register(chip, CLK_CTL, CLK_LOW_FREQ, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -790,49 +787,44 @@ int switch_normal_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, CLK_LOW_FREQ);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
}
retval = rtsx_write_register(chip, CLK_DIV, 0xFF,
(div << 4) | mcu_cnt);
- if (retval) {
+ if (retval)
return retval;
- }
retval = rtsx_write_register(chip, CLK_SEL, 0xFF, sel);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
udelay(200);
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
udelay(200);
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -878,9 +870,8 @@ int enable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, clk_en);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -898,9 +889,8 @@ int disable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, 0);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -924,9 +914,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val1);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
udelay(chip->pmos_pwr_on_interval);
@@ -934,9 +923,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val2);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -955,9 +943,8 @@ int card_power_off(struct rtsx_chip *chip, u8 card)
}
retval = rtsx_write_register(chip, CARD_PWR_CTL, mask, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -969,9 +956,8 @@ int card_rw(struct scsi_cmnd *srb, struct rtsx_chip *chip,
unsigned int lun = SCSI_LUN(srb);
int i;
- if (!chip->rw_card[lun]) {
+ if (!chip->rw_card[lun])
[PATCH v2 03/15] platform: goldfish: pipe: Move the file-scope goldfish_pipe_dev variable into the driver state
From: Roman Kiryanov
This is the last patch in the series of patches to move file-scope
variables into the driver state. This change will help to introduce
another version of the pipe driver (with different state) for the
older host interface or having several instances of this device.
Signed-off-by: Roman Kiryanov
---
Changes in v2:
- Updated the commit message.
drivers/platform/goldfish/goldfish_pipe.c | 66 +--
1 file changed, 37 insertions(+), 29 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 8ca709b45e1f..4013832f38fb 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -169,6 +169,9 @@ struct goldfish_pipe {
* waiting to be awoken.
*/
struct goldfish_pipe_dev {
+ /* A magic number to check if this is an instance of this struct */
+ void *magic;
+
/*
* Global device spinlock. Protects the following members:
* - pipes, pipes_capacity
@@ -215,8 +218,6 @@ struct goldfish_pipe_dev {
struct miscdevice miscdev;
};
-static struct goldfish_pipe_dev goldfish_pipe_dev;
-
static int goldfish_pipe_cmd_locked(struct goldfish_pipe *pipe,
enum PipeCmdCode cmd)
{
@@ -611,6 +612,9 @@ static void goldfish_interrupt_task(unsigned long dev_addr)
}
}
+static void goldfish_pipe_device_deinit(struct platform_device *pdev,
+ struct goldfish_pipe_dev *dev);
+
/*
* The general idea of the interrupt handling:
*
@@ -631,7 +635,7 @@ static irqreturn_t goldfish_pipe_interrupt(int irq, void
*dev_id)
unsigned long flags;
struct goldfish_pipe_dev *dev = dev_id;
- if (dev != &goldfish_pipe_dev)
+ if (dev->magic != &goldfish_pipe_device_deinit)
return IRQ_NONE;
/* Request the signalled pipes from the device */
@@ -683,6 +687,14 @@ static int get_free_pipe_id_locked(struct
goldfish_pipe_dev *dev)
return id;
}
+/* A helper function to get the instance of goldfish_pipe_dev from file */
+static struct goldfish_pipe_dev *to_goldfish_pipe_dev(struct file *file)
+{
+ struct miscdevice *miscdev = file->private_data;
+
+ return container_of(miscdev, struct goldfish_pipe_dev, miscdev);
+}
+
/**
* goldfish_pipe_open - open a channel to the AVD
* @inode: inode of device
@@ -696,7 +708,7 @@ static int get_free_pipe_id_locked(struct goldfish_pipe_dev
*dev)
*/
static int goldfish_pipe_open(struct inode *inode, struct file *file)
{
- struct goldfish_pipe_dev *dev = &goldfish_pipe_dev;
+ struct goldfish_pipe_dev *dev = to_goldfish_pipe_dev(file);
unsigned long flags;
int id;
int status;
@@ -804,9 +816,9 @@ static void write_pa_addr(void *addr, void __iomem *portl,
void __iomem *porth)
writel(lower_32_bits(paddr), portl);
}
-static int goldfish_pipe_device_init(struct platform_device *pdev)
+static int goldfish_pipe_device_init(struct platform_device *pdev,
+struct goldfish_pipe_dev *dev)
{
- struct goldfish_pipe_dev *dev = &goldfish_pipe_dev;
int err;
tasklet_init(&dev->irq_tasklet, &goldfish_interrupt_task,
@@ -861,26 +873,29 @@ static int goldfish_pipe_device_init(struct
platform_device *pdev)
dev->base + PIPE_REG_OPEN_BUFFER,
dev->base + PIPE_REG_OPEN_BUFFER_HIGH);
+ platform_set_drvdata(pdev, dev);
return 0;
}
-static void goldfish_pipe_device_deinit(struct platform_device *pdev)
+static void goldfish_pipe_device_deinit(struct platform_device *pdev,
+ struct goldfish_pipe_dev *dev)
{
- misc_deregister(&goldfish_pipe_dev.miscdev);
- tasklet_kill(&goldfish_pipe_dev.irq_tasklet);
- kfree(goldfish_pipe_dev.pipes);
- free_page((unsigned long)goldfish_pipe_dev.buffers);
+ misc_deregister(&dev->miscdev);
+ tasklet_kill(&dev->irq_tasklet);
+ kfree(dev->pipes);
+ free_page((unsigned long)dev->buffers);
}
static int goldfish_pipe_probe(struct platform_device *pdev)
{
- int err;
struct resource *r;
- struct goldfish_pipe_dev *dev = &goldfish_pipe_dev;
+ struct goldfish_pipe_dev *dev;
- /* not thread safe, but this should not happen */
- WARN_ON(dev->base);
+ dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+ dev->magic = &goldfish_pipe_device_deinit;
spin_lock_init(&dev->lock);
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -895,10 +910,9 @@ static int goldfish_pipe_probe(struct platform_device
*pdev)
}
r = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!r) {
- err = -EINVAL;
- goto error;
- }
+ if (!
[PATCH v2 01/15] platform: goldfish: pipe: Move the file-scope goldfish_interrupt_tasklet variable into the driver state
From: Roman Kiryanov
This is a series of patches to move mutable file-scope variables
into the driver state. This change will help to introduce another
version of the pipe driver (with different state) for the older
host interface or having several instances of this device.
Signed-off-by: Roman Kiryanov
---
Changes in v2:
- Updated the commit message.
drivers/platform/goldfish/goldfish_pipe.c | 24 +++
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 56665e879e5a..ba9aede17d57 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -208,6 +208,9 @@ struct goldfish_pipe_dev {
int irq;
int version;
unsigned char __iomem *base;
+
+ /* an irq tasklet to run goldfish_interrupt_task */
+ struct tasklet_struct irq_tasklet;
};
static struct goldfish_pipe_dev goldfish_pipe_dev;
@@ -582,14 +585,14 @@ static struct goldfish_pipe *signalled_pipes_pop_front(
return pipe;
}
-static void goldfish_interrupt_task(unsigned long unused)
+static void goldfish_interrupt_task(unsigned long dev_addr)
{
/* Iterate over the signalled pipes and wake them one by one */
+ struct goldfish_pipe_dev *dev = (struct goldfish_pipe_dev *)dev_addr;
struct goldfish_pipe *pipe;
int wakes;
- while ((pipe = signalled_pipes_pop_front(&goldfish_pipe_dev, &wakes)) !=
- NULL) {
+ while ((pipe = signalled_pipes_pop_front(dev, &wakes)) != NULL) {
if (wakes & PIPE_WAKE_CLOSED) {
pipe->flags = 1 << BIT_CLOSED_ON_HOST;
} else {
@@ -605,7 +608,6 @@ static void goldfish_interrupt_task(unsigned long unused)
wake_up_interruptible(&pipe->wake_queue);
}
}
-static DECLARE_TASKLET(goldfish_interrupt_tasklet, goldfish_interrupt_task, 0);
/*
* The general idea of the interrupt handling:
@@ -648,7 +650,7 @@ static irqreturn_t goldfish_pipe_interrupt(int irq, void
*dev_id)
spin_unlock_irqrestore(&dev->lock, flags);
- tasklet_schedule(&goldfish_interrupt_tasklet);
+ tasklet_schedule(&dev->irq_tasklet);
return IRQ_HANDLED;
}
@@ -800,9 +802,14 @@ static void write_pa_addr(void *addr, void __iomem *portl,
void __iomem *porth)
static int goldfish_pipe_device_init(struct platform_device *pdev)
{
struct goldfish_pipe_dev *dev = &goldfish_pipe_dev;
- int err = devm_request_irq(&pdev->dev, dev->irq,
- goldfish_pipe_interrupt,
- IRQF_SHARED, "goldfish_pipe", dev);
+ int err;
+
+ tasklet_init(&dev->irq_tasklet, &goldfish_interrupt_task,
+(unsigned long)dev);
+
+ err = devm_request_irq(&pdev->dev, dev->irq,
+ goldfish_pipe_interrupt,
+ IRQF_SHARED, "goldfish_pipe", dev);
if (err) {
dev_err(&pdev->dev, "unable to allocate IRQ for v2\n");
return err;
@@ -854,6 +861,7 @@ static int goldfish_pipe_device_init(struct platform_device
*pdev)
static void goldfish_pipe_device_deinit(struct platform_device *pdev)
{
misc_deregister(&goldfish_pipe_miscdev);
+ tasklet_kill(&goldfish_pipe_dev.irq_tasklet);
kfree(goldfish_pipe_dev.pipes);
free_page((unsigned long)goldfish_pipe_dev.buffers);
}
--
2.19.0.605.g01d371f741-goog
[PATCH v2 02/15] platform: goldfish: pipe: Move the file-scope goldfish_pipe_miscdev variable into the driver state
From: Roman Kiryanov
This is a series of patches to move mutable file-scope variables
into the driver state. This change will help to introduce another
version of the pipe driver (with different state) for the older
host interface or having several instances of this device.
Signed-off-by: Roman Kiryanov
---
Changes in v2:
- Updated the commit message.
drivers/platform/goldfish/goldfish_pipe.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index ba9aede17d57..8ca709b45e1f 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -211,6 +211,8 @@ struct goldfish_pipe_dev {
/* an irq tasklet to run goldfish_interrupt_task */
struct tasklet_struct irq_tasklet;
+
+ struct miscdevice miscdev;
};
static struct goldfish_pipe_dev goldfish_pipe_dev;
@@ -785,11 +787,14 @@ static const struct file_operations goldfish_pipe_fops = {
.release = goldfish_pipe_release,
};
-static struct miscdevice goldfish_pipe_miscdev = {
- .minor = MISC_DYNAMIC_MINOR,
- .name = "goldfish_pipe",
- .fops = &goldfish_pipe_fops,
-};
+static void init_miscdevice(struct miscdevice *miscdev)
+{
+ memset(miscdev, 0, sizeof(*miscdev));
+
+ miscdev->minor = MISC_DYNAMIC_MINOR;
+ miscdev->name = "goldfish_pipe";
+ miscdev->fops = &goldfish_pipe_fops;
+}
static void write_pa_addr(void *addr, void __iomem *portl, void __iomem *porth)
{
@@ -815,7 +820,8 @@ static int goldfish_pipe_device_init(struct platform_device
*pdev)
return err;
}
- err = misc_register(&goldfish_pipe_miscdev);
+ init_miscdevice(&dev->miscdev);
+ err = misc_register(&dev->miscdev);
if (err) {
dev_err(&pdev->dev, "unable to register v2 device\n");
return err;
@@ -860,7 +866,7 @@ static int goldfish_pipe_device_init(struct platform_device
*pdev)
static void goldfish_pipe_device_deinit(struct platform_device *pdev)
{
- misc_deregister(&goldfish_pipe_miscdev);
+ misc_deregister(&goldfish_pipe_dev.miscdev);
tasklet_kill(&goldfish_pipe_dev.irq_tasklet);
kfree(goldfish_pipe_dev.pipes);
free_page((unsigned long)goldfish_pipe_dev.buffers);
--
2.19.0.605.g01d371f741-goog
Re: [PATCH v6 3/5] tools, perf, script: Add --call-trace and --call-ret-trace
On Tue, Oct 02, 2018 at 11:24:56AM -0300, Arnaldo Carvalho de Melo wrote: > Em Sat, Sep 29, 2018 at 03:39:03PM +0800, leo@linaro.org escreveu: > > On Fri, Sep 28, 2018 at 10:19:44AM -0700, Andi Kleen wrote: > > > > Seems to me, these two features are _NOT_ only benefit for intel_pt, > > > > other hardware tracing (e.g. Arm CoreSight) can enable these features > > > > as well. This patch is to document only for intel_pt, later if we > > > > enable this feature on Arm platform we need to change the doc; > > > > alternatively we can use more general description for these two options > > > > at the first place. How about you think for this? > > > > > > Likely it already works for CoreSight > > > > I think Kim played with this patch series and he also pointed me for > > this series. > > > > > I specified intel_pt, because if we just say traces the users won't > > > know what PMU to specify for record. Being too abstract is > > > often not helpful. > > > > > > If someone successfully tests it on CoreSight they could submit > > > a patch to the documentation to add "or " to these > > > two cases. That would make it then clear for those users too. > > > > Okay, agree. > > > > Actually I applied your patch series v6 on the perf latest core branch > > and tested on Arm Juno board, I observed there have couple issues, one > > is CoreSight trace data doesn't support timestamp so I need to use > > '-F,-time' to workaround the command failure; another issue is now > > CoreSight is absent to set sample flags so perf fails to resolve > > symbols [1]; these two issues are only related with CoreSight decoder > > and it's no matter with this patch, so I didn't mention in my previous > > replying. > > Could I take that as a Tested-by? I.e. you actually applied the patches, > run it and saw that it works as advertised, right? Yes, Arnaldo. This is my testing tag: Tested-by: Leo Yan > - Arnaldo > > > I need a bit more time to work out more formal CoreSight fixing patches > > and will send for reviewing (also will include one patch to clarifying > > Arm Coresight support in doc as suggested). > > > > Thanks, > > Leo Yan > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools/perf/builtin-script.c?h=perf/core#n1128
[PATCH 1/2] ARM: dts: uniphier: add SD/eMMC controller nodes
Add SD controller nodes for LD4, Pro4, sLD8, Pro5, and PXs2.
This is also used as an eMMC controller for LD4, Pro4, and sLD8.
Signed-off-by: Masahiro Yamada
---
arch/arm/boot/dts/uniphier-ld4-ref.dts | 4 +++
arch/arm/boot/dts/uniphier-ld4.dtsi| 34 +
arch/arm/boot/dts/uniphier-ld6b-ref.dts| 4 +++
arch/arm/boot/dts/uniphier-pinctrl.dtsi| 5
arch/arm/boot/dts/uniphier-pro4-ace.dts| 4 +++
arch/arm/boot/dts/uniphier-pro4-ref.dts| 4 +++
arch/arm/boot/dts/uniphier-pro4-sanji.dts | 4 +++
arch/arm/boot/dts/uniphier-pro4.dtsi | 48 ++
arch/arm/boot/dts/uniphier-pro5.dtsi | 34 +
arch/arm/boot/dts/uniphier-pxs2-gentil.dts | 4 +++
arch/arm/boot/dts/uniphier-pxs2-vodka.dts | 4 +++
arch/arm/boot/dts/uniphier-pxs2.dtsi | 34 +
arch/arm/boot/dts/uniphier-sld8-ref.dts| 4 +++
arch/arm/boot/dts/uniphier-sld8.dtsi | 34 +
14 files changed, 221 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ld4-ref.dts
index 21407e1..3aaca10 100644
--- a/arch/arm/boot/dts/uniphier-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld4-ref.dts
@@ -63,6 +63,10 @@
status = "okay";
};
+&sd {
+ status = "okay";
+};
+
&usb0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ld4.dtsi
index 2a17066..fa00ec8 100644
--- a/arch/arm/boot/dts/uniphier-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
@@ -224,6 +224,40 @@
};
};
+ sd: sdhc@5a40 {
+ compatible = "socionext,uniphier-sd-v2.91";
+ status = "disabled";
+ reg = <0x5a40 0x200>;
+ interrupts = <0 76 4>;
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&pinctrl_sd>;
+ pinctrl-1 = <&pinctrl_sd_uhs>;
+ clocks = <&mio_clk 0>;
+ reset-names = "host", "bridge";
+ resets = <&mio_rst 0>, <&mio_rst 3>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ };
+
+ emmc: sdhc@5a50 {
+ compatible = "socionext,uniphier-sd-v2.91";
+ status = "disabled";
+ reg = <0x5a50 0x200>;
+ interrupts = <0 78 4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_emmc>;
+ clocks = <&mio_clk 1>;
+ reset-names = "host", "bridge", "hw";
+ resets = <&mio_rst 1>, <&mio_rst 4>, <&mio_rst 6>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ cap-mmc-hw-reset;
+ non-removable;
+ };
+
usb0: usb@5a800100 {
compatible = "socionext,uniphier-ehci", "generic-ehci";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ld6b-ref.dts
b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
index a0a44a4..e505a94 100644
--- a/arch/arm/boot/dts/uniphier-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ld6b-ref.dts
@@ -65,6 +65,10 @@
status = "okay";
};
+&sd {
+ status = "okay";
+};
+
ð {
status = "okay";
phy-handle = <ðphy>;
diff --git a/arch/arm/boot/dts/uniphier-pinctrl.dtsi
b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
index 51f0e69..aeb47b0 100644
--- a/arch/arm/boot/dts/uniphier-pinctrl.dtsi
+++ b/arch/arm/boot/dts/uniphier-pinctrl.dtsi
@@ -121,6 +121,11 @@
function = "sd";
};
+ pinctrl_sd_uhs: sd-uhs {
+ groups = "sd";
+ function = "sd";
+ };
+
pinctrl_sd1: sd1 {
groups = "sd1";
function = "sd1";
diff --git a/arch/arm/boot/dts/uniphier-pro4-ace.dts
b/arch/arm/boot/dts/uniphier-pro4-ace.dts
index db1b089..46e0917 100644
--- a/arch/arm/boot/dts/uniphier-pro4-ace.dts
+++ b/arch/arm/boot/dts/uniphier-pro4-ace.dts
@@ -68,6 +68,10 @@
status = "okay";
};
+&sd {
+ status = "okay";
+};
+
&usb2 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/uniphier-pro4-ref.dts
b/arch/arm/boot/dts/uniphier-pro4-ref.dts
index efb0849..1429908 100644
--- a/arch/arm/boot/dts/uniphier-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-pro4-ref.dts
@@ -65,6 +65,10 @@
status = "okay";
};
+&sd {
+ status = "okay";
+};
+
&usb2 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/uniphier-pro4-sanji.dts
b/arch/arm/boot/dts/uniphier-pro4-sanji.dts
index dac4d66..eaca4a7 1006
[PATCH 2/2] arm64: dts: uniphier: add SD controller nodes
Add SD controller nodes for LD20 and PXs3.
LD20 does not support the UHS mode, while PXs3 supports it.
Signed-off-by: Masahiro Yamada
---
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi| 14 ++
arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts | 4
arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi| 18 ++
3 files changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index 6932cef..ee92605 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -528,6 +528,20 @@
cdns,phy-dll-delay-sdclk-hsmmc = <21>;
};
+ sd: sdhc@5a40 {
+ compatible = "socionext,uniphier-sd-v3.1.1";
+ status = "disabled";
+ reg = <0x5a40 0x800>;
+ interrupts = <0 76 4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sd>;
+ clocks = <&sd_clk 0>;
+ reset-names = "host";
+ resets = <&sd_rst 0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ };
+
soc_glue: soc-glue@5f80 {
compatible = "socionext,uniphier-ld20-soc-glue",
"simple-mfd", "syscon";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts
b/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts
index c1bb607..1ad149c 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts
@@ -75,6 +75,10 @@
status = "okay";
};
+&sd {
+ status = "okay";
+};
+
ð0 {
status = "okay";
phy-handle = <ðphy0>;
diff --git a/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
b/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
index fd2bcd4..f3f19f5 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi
@@ -341,6 +341,24 @@
cdns,phy-dll-delay-sdclk-hsmmc = <21>;
};
+ sd: sdhc@5a40 {
+ compatible = "socionext,uniphier-sd-v3.1.1";
+ status = "disabled";
+ reg = <0x5a40 0x800>;
+ interrupts = <0 76 4>;
+ pinctrl-names = "default", "uhs";
+ pinctrl-0 = <&pinctrl_sd>;
+ pinctrl-1 = <&pinctrl_sd_uhs>;
+ clocks = <&sd_clk 0>;
+ reset-names = "host";
+ resets = <&sd_rst 0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ };
+
soc_glue: soc-glue@5f80 {
compatible = "socionext,uniphier-pxs3-soc-glue",
"simple-mfd", "syscon";
--
2.7.4
Re: [PATCH 1/2] mmc: tmio: move MFD variant reset to a platform hook
Hi Yamada-san,
On Mon, Oct 01, 2018 at 09:31:01PM +0900, Masahiro Yamada wrote:
> CTL_RESET_SDIO register is specific to the TMIO MFD (tmio_mmc.c).
>
> Add a new hook host->reset for performing a platform-specific reset
> sequence, and move CTL_RESET_SDIO over there.
>
> Signed-off-by: Masahiro Yamada
I like it in general.
> +static void tmio_mmc_reset(struct tmio_mmc_host *host)
> +{
> + sd_ctrl_write16(host, CTL_RESET_SDIO, 0x);
> + usleep_range(1, 11000);
> + sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0001);
> + usleep_range(1, 11000);
> +}
> +
Are you sure resetting SDIO works independently of resetting SD? Maybe
we should add resetting SD here, too, to keep the pattern...
> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c
> @@ -164,14 +164,13 @@ static void tmio_mmc_reset(struct tmio_mmc_host *host)
> {
> /* FIXME - should we set stop clock reg here */
> sd_ctrl_write16(host, CTL_RESET_SD, 0x);
> - if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
> - sd_ctrl_write16(host, CTL_RESET_SDIO, 0x);
> usleep_range(1, 11000);
> sd_ctrl_write16(host, CTL_RESET_SD, 0x0001);
> - if (host->pdata->flags & TMIO_MMC_HAVE_HIGH_REG)
> - sd_ctrl_write16(host, CTL_RESET_SDIO, 0x0001);
> usleep_range(1, 11000);
... and have this simplified reset pattern either also in a seperate
function, or doing...
>
> + if (host->reset)
> + host->reset(host);
else
simplified_reset_pattern
?
What's your opinion?
Regards,
Wolfram
signature.asc
Description: PGP signature
Re: [PATCHv1 00/14] power: supply: Fix custom sysfs attribute registration
On Mon, Oct 01, 2018 at 12:03:35AM +0200, Sebastian Reichel wrote: > Hi, > > Udev may not detect sysfs attributes, that have been added > after the device has been created. Code doing that is racy [0]. > The power-supply class properly registers its attributes > when the device is created, but some drivers add additional > custom attributes in a racy way. > > The first patch from this series adds native support for custom > sysfs attributes to the power-supply subsystem. This feature > allows cleaner code and avoids a race condition preventing udev > from noticing the custom properties. > > The following patches replace all instances of sysfs_create_* > in drivers/power/supply to use the new feature and a couple > of small cleanups. > > TL;DR: This patchsets replaces all sysfs_create_* in power-supply. > > [0] http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/ > > -- Sebastian > > Sebastian Reichel (14): > power: supply: core: add support for custom sysfs attributes > power: supply: bq2415x: fix race-condition in sysfs registration > power: supply: ds2780: fix race-condition in sysfs registration > power: supply: ds2781: fix race-condition in sysfs registration > power: supply: lp8788: fix race-condition in sysfs registration > power: supply: bq24190_charger: fix race-condition in sysfs > registration > power: supply: bq24257: fix race-condition in sysfs registration > power: supply: charger-manager: simplify generation of sysfs attribute > group name > power: supply: charger-manager: fix race-condition in sysfs > registration > power: supply: pcf50633: fix race-condition in sysfs registration > power: supply: ds2780: fix race-condition in bin attribute > registration > power: supply: ds2781: fix race-condition in bin attribute > registration > power: supply: ds2780: switch to devm_power_supply_register > power: supply: ds2781: switch to devm_power_supply_register > > drivers/power/supply/bq2415x_charger.c | 119 ++- > drivers/power/supply/bq24190_charger.c | 43 ++-- > drivers/power/supply/bq24257_charger.c | 15 +-- > drivers/power/supply/charger-manager.c | 62 +--- > drivers/power/supply/ds2780_battery.c| 87 + > drivers/power/supply/ds2781_battery.c| 82 +--- > drivers/power/supply/lp8788-charger.c| 62 +--- > drivers/power/supply/pcf50633-charger.c | 17 ++-- > drivers/power/supply/power_supply_core.c | 1 + > include/linux/power/charger-manager.h| 3 +- > include/linux/power_supply.h | 3 + > 11 files changed, 172 insertions(+), 322 deletions(-) Nice work, and it removes more code than it adds, always a win. greg k-h
Re: [PATCH] misc: cxl: Move a deference below a NULL test
On Wed, Sep 26, 2018 at 07:41:12PM +0800, zhong jiang wrote:
> It is safe to move a deference below a NULL test.
>
> Signed-off-by: zhong jiang
> Acked-by: Andrew Donnellan
> ---
> drivers/misc/cxl/guest.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
> index 3bc0c15..559e835 100644
> --- a/drivers/misc/cxl/guest.c
> +++ b/drivers/misc/cxl/guest.c
> @@ -1018,11 +1018,11 @@ int cxl_guest_init_afu(struct cxl *adapter, int
> slice, struct device_node *afu_n
>
> void cxl_guest_remove_afu(struct cxl_afu *afu)
> {
> - pr_devel("in %s - AFU(%d)\n", __func__, afu->slice);
> -
> if (!afu)
> return;
>
> + pr_devel("in %s - AFU(%d)\n", __func__, afu->slice);
> +
This call should just be deleted, ftrace can be used if this type of
thing is really needed.
thanks,
greg k-h
Re: [PATCH] pinctrl: qcom: fix 'const' pointer handling
On Tue 02 Oct 14:15 PDT 2018, Arnd Bergmann wrote:
> The 'tiles' array is initialized to a constant pointers to constant
> strings, but the declaration is only half as constant:
>
> drivers/pinctrl/qcom/pinctrl-qcs404.c:1660:11: error: initialization discards
> 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
> drivers/pinctrl/qcom/pinctrl-sdm660.c:1417:11: error: initialization discards
> 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
>
> Let's make it more constant.
>
> Fixes: 22eb8301dbc1 ("pinctrl: qcom: Add qcs404 pinctrl driver")
> Fixes: a46d5e98190d ("pinctrl: qcom: Support dispersed tiles")
> Signed-off-by: Arnd Bergmann
Not sure why my compiler doesn't complain about this, thanks for the fix
Arnd.
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/pinctrl/qcom/pinctrl-msm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.h
> b/drivers/pinctrl/qcom/pinctrl-msm.h
> index 0ad4bc55e2e1..29172fdf5882 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.h
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.h
> @@ -119,7 +119,7 @@ struct msm_pinctrl_soc_data {
> unsigned ngroups;
> unsigned ngpios;
> bool pull_no_keeper;
> - const char **tiles;
> + const char *const *tiles;
> unsigned int ntiles;
> };
>
> --
> 2.18.0
>
[PATCH] [v4] HID: add support for Apple Magic Trackpad 2
USB device
Vendor 05ac (Apple)
Device 0265 (Magic Trackpad 2)
Bluetooth device
Vendor 004c (Apple)
Device 0265 (Magic Trackpad 2)
Add support for Apple Magic Trackpad 2 over USB and bluetooth, putting
the device in multi-touch mode.
Signed-off-by: Claudio Mettler
Signed-off-by: Marek Wyborski
Signed-off-by: Sean O'Brien
---
drivers/hid/hid-ids.h| 1 +
drivers/hid/hid-magicmouse.c | 142 ---
2 files changed, 132 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 5146ee029db4..bb0cd212c7cc 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -92,6 +92,7 @@
#define USB_DEVICE_ID_APPLE_MIGHTYMOUSE0x0304
#define USB_DEVICE_ID_APPLE_MAGICMOUSE 0x030d
#define USB_DEVICE_ID_APPLE_MAGICTRACKPAD 0x030e
+#define USB_DEVICE_ID_APPLE_MAGICTRACKPAD2 0x0265
#define USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI 0x020e
#define USB_DEVICE_ID_APPLE_FOUNTAIN_ISO 0x020f
#define USB_DEVICE_ID_APPLE_GEYSER_ANSI0x0214
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index b454c4386157..1d5ea678d268 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -54,6 +54,8 @@ module_param(report_undeciphered, bool, 0644);
MODULE_PARM_DESC(report_undeciphered, "Report undeciphered multi-touch state
field using a MSC_RAW event");
#define TRACKPAD_REPORT_ID 0x28
+#define TRACKPAD2_USB_REPORT_ID 0x02
+#define TRACKPAD2_BT_REPORT_ID 0x31
#define MOUSE_REPORT_ID0x29
#define DOUBLE_REPORT_ID 0xf7
/* These definitions are not precise, but they're close enough. (Bits
@@ -91,6 +93,17 @@ MODULE_PARM_DESC(report_undeciphered, "Report undeciphered
multi-touch state fie
#define TRACKPAD_RES_Y \
((TRACKPAD_MAX_Y - TRACKPAD_MIN_Y) / (TRACKPAD_DIMENSION_Y / 100))
+#define TRACKPAD2_DIMENSION_X (float)16000
+#define TRACKPAD2_MIN_X -3678
+#define TRACKPAD2_MAX_X 3934
+#define TRACKPAD2_RES_X \
+ ((TRACKPAD2_MAX_X - TRACKPAD2_MIN_X) / (TRACKPAD2_DIMENSION_X / 100))
+#define TRACKPAD2_DIMENSION_Y (float)11490
+#define TRACKPAD2_MIN_Y -2478
+#define TRACKPAD2_MAX_Y 2587
+#define TRACKPAD2_RES_Y \
+ ((TRACKPAD2_MAX_Y - TRACKPAD2_MIN_Y) / (TRACKPAD2_DIMENSION_Y / 100))
+
/**
* struct magicmouse_sc - Tracks Magic Mouse-specific data.
* @input: Input device through which we report events.
@@ -183,6 +196,7 @@ static void magicmouse_emit_touch(struct magicmouse_sc
*msc, int raw_id, u8 *tda
{
struct input_dev *input = msc->input;
int id, x, y, size, orientation, touch_major, touch_minor, state, down;
+ int pressure = 0;
if (input->id.product == USB_DEVICE_ID_APPLE_MAGICMOUSE) {
id = (tdata[6] << 2 | tdata[5] >> 6) & 0xf;
@@ -194,6 +208,17 @@ static void magicmouse_emit_touch(struct magicmouse_sc
*msc, int raw_id, u8 *tda
touch_minor = tdata[4];
state = tdata[7] & TOUCH_STATE_MASK;
down = state != TOUCH_STATE_NONE;
+ } else if (input->id.product == USB_DEVICE_ID_APPLE_MAGICTRACKPAD2) {
+ id = tdata[8] & 0xf;
+ x = (tdata[1] << 27 | tdata[0] << 19) >> 19;
+ y = -((tdata[3] << 30 | tdata[2] << 22 | tdata[1] << 14) >> 19);
+ size = tdata[6];
+ orientation = (tdata[8] >> 5) - 4;
+ touch_major = tdata[4];
+ touch_minor = tdata[5];
+ pressure = tdata[7];
+ state = tdata[3] & 0xC0;
+ down = state == 0x80;
} else { /* USB_DEVICE_ID_APPLE_MAGICTRACKPAD */
id = (tdata[7] << 2 | tdata[6] >> 6) & 0xf;
x = (tdata[1] << 27 | tdata[0] << 19) >> 19;
@@ -215,7 +240,8 @@ static void magicmouse_emit_touch(struct magicmouse_sc
*msc, int raw_id, u8 *tda
/* If requested, emulate a scroll wheel by detecting small
* vertical touch motions.
*/
- if (emulate_scroll_wheel) {
+ if (emulate_scroll_wheel && (input->id.product !=
+ USB_DEVICE_ID_APPLE_MAGICTRACKPAD2)) {
unsigned long now = jiffies;
int step_x = msc->touches[id].scroll_x - x;
int step_y = msc->touches[id].scroll_y - y;
@@ -269,10 +295,14 @@ static void magicmouse_emit_touch(struct magicmouse_sc
*msc, int raw_id, u8 *tda
input_report_abs(input, ABS_MT_POSITION_X, x);
input_report_abs(input, ABS_MT_POSITION_Y, y);
+ if (input->id.product == USB_DEVICE_ID_APPLE_MAGICTRACKPAD2)
+ input_report_abs(input, ABS_MT_PRESSURE, pressure);
+
if (report_undeciphered) {
if (input->id.product == USB_DEVICE_ID_APPLE_MAGICMOUSE)
input_event(input, EV_MSC, MSC_RAW, tdata[7]);
- else /* USB_DEVICE_ID_APPLE_MAGICTRACKPAD */
+
[PATCH] x86/cpu/amd: Remove unnecessary parentheses
Clang warns when multiple pairs of parentheses are used for a single
conditional statement.
arch/x86/kernel/cpu/amd.c:925:14: warning: equality comparison with
extraneous parentheses [-Wparentheses-equality]
if ((c->x86 == 6)) {
~~~^~~~
arch/x86/kernel/cpu/amd.c:925:14: note: remove extraneous parentheses
around the comparison to silence this warning
if ((c->x86 == 6)) {
~ ^ ~
arch/x86/kernel/cpu/amd.c:925:14: note: use '=' to turn this equality
comparison into an assignment
if ((c->x86 == 6)) {
^~
=
1 warning generated.
Link: https://github.com/ClangBuiltLinux/linux/issues/187
Signed-off-by: Nathan Chancellor
---
arch/x86/kernel/cpu/amd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 22ab408177b2..eeea634bee0a 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -922,7 +922,7 @@ static void init_amd(struct cpuinfo_x86 *c)
static unsigned int amd_size_cache(struct cpuinfo_x86 *c, unsigned int size)
{
/* AMD errata T13 (order #21922) */
- if ((c->x86 == 6)) {
+ if (c->x86 == 6) {
/* Duron Rev A0 */
if (c->x86_model == 3 && c->x86_stepping == 0)
size = 64;
--
2.19.0
Re: Leaking Path in XFS's ioctl interface(missing LSM check)
On Wed, Oct 03, 2018 at 05:20:31AM +1000, James Morris wrote: > On Tue, 2 Oct 2018, Dave Chinner wrote: > > > On Tue, Oct 02, 2018 at 06:08:16AM +1000, James Morris wrote: > > > On Mon, 1 Oct 2018, Darrick J. Wong wrote: > > > > > > > If we /did/ replace CAP_SYS_ADMIN checking with a pile of LSM hooks, > > > > > > Not sure we'd need a pile of hooks, what about just "read" and "write" > > > storage admin? > > > > > > Or even two new capabilities along these lines, which we convert existing > > > CAP_SYS_ADMIN etc. to? > > > > So instead of having hundreds of management ioctls under > > CAP_SYS_ADMIN, we'd now have hundreds of non-storage ioctls under > > CAP_SYS_ADMIN and hundreds of storage ioctls under > > CAP_SYS_STORAGE_ADMIN? > > > > Maybe I'm missing something, but I don't see how that improves the > > situation w.r.t. locked down LSM configurations? > > I'm not sure about capabilities, but having two specific LSM hooks for > storage admin would allow SELinux et al to explicitly control privileged > access to these interfaces. Storage admin seems to be a special case of > its own which we want to be able to mediate as such. Perhaps so - as a stepping stone it would allow isolation in specific cases where no management should be allowed, but there are cases with modern filesystems where users need access to storage APIs. e.g. It's entirely plausible that /home is set up as a subvolume per user, and that subvols in a fileystem can be independently snapshotted. Hence it would be completely acceptible to allow users to have access to snapshot management APIs to be able to snapshot their home directories for backup/rollback purposes. Hence I'm not sure that black/white storage admin LSM hooks are a solution that will end up being particularly useful to the wider population... Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH 01/15] platform: goldfish: pipe: Remove the goldfish_interrupt_tasklet global variable
On Tue, Oct 02, 2018 at 03:33:11PM -0700, Roman Kiryanov wrote: > > I don't see a "global" variable here, what are you referring to. > > > > This one: > > > > > -static DECLARE_TASKLET(goldfish_interrupt_tasklet, > > > goldfish_interrupt_task, 0); > > > > ? > > Yes. > > > That looks static to this file to me. > > what am I missing here? > > It has a global lifetime but it is visible only in this file. How do I > say better, just drop the word "global"? Yes. It's not a global variable at all. It's file-scope only. What you are doing is moving the variable to be attached to the device itself, allowing you to have multiple devices handled by the same code, which is great. But please document it as such. Same goes for the other patches in this series. thanks, greg k-h
