Re: [PATCH] ARM: imx6q: Add missing esai_ahb clock to current clock tree
On Thu, Jan 09, 2014 at 03:41:38PM +0800, Nicolin Chen wrote:
> On Thu, Jan 09, 2014 at 02:57:42PM +0800, Shawn Guo wrote:
> > On Thu, Jan 09, 2014 at 11:49:41AM +0800, Nicolin Chen wrote:
> > > On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > > > > static struct clk *clk[clk_max];
> > > > > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct
> > > > > device_node *ccm_node)
> > > > > clk[ecspi5] = imx_clk_gate2("ecspi5",
> > > > > "ecspi_root",base + 0x6c, 8);
> > > > > clk[enet] = imx_clk_gate2("enet", "ipg",
> > > > > base + 0x6c, 10);
> > > > > clk[esai] = imx_clk_gate2("esai", "esai_podf",
> > > > > base + 0x6c, 16);
> > > > > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb",
> > > > > base + 0x6c, 16);
> > > >
> > > > Hmm, having two clocks operating on the same gate bit will get us
> > > > problem in clock disabling. Clock enabling is fine, since either
> > > > one who calls clk_enable() first will just set the gate bit. But in
> > > > case that clk_enable() is called on both clocks, and then when either
> > > > clock calls clk_disable(), the gate bit will be cleared and thus breaks
> > > > the other one that might still be in use.
> > >
> > > Understood. But how could we handle this situation? The only way I can
> > > figure
> > > out is to make sure the driver open/close them at the same time, it's not
> > > a
> > > perfect way though.
> >
> > Hmm, we generally leave the gate bit to the clock used to access
> > register, because usually it's the first one to be on and the last one
> > to be off.
>
> Then we should attach CLK_IGNORE_UNUSED to clk[esai] since clk[esai_ahb] is
> the clock used to access memory, shouldn't we?
Please wait for Mikes input or let's look how a proper solution can look
like. I've already seen the case that a single bit controls multiple
clocks. Hacking around this issue each time is not a solution.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv8 RFC] pwm: Add Freescale FTM PWM driver support
> > +static unsigned long fsl_pwm_calculate_period_cycles(struct fsl_pwm_chip
> *fpc,
> > +unsigned long period_ns,
> > +enum fsl_pwm_clk index)
> > +{
> > + bool bg = fpc->big_endian;
> > + int ret;
> > +
> > + fpc->counter_clk_select = FTM_SC_CLK(bg, index);
>
> Yes, this is the spirit of what I was suggesting. The code is much less
> efficient/bigger on the Vybrid with this run-time detection; but this is
> more efficient/smaller than previous versions. I think that 'bg' can be
> a compiler '#define' base on the configured SOC-systems. Ie, if the
> kernel config only has 'Vybrid' or only 'LayerScape', then 'bg' can be a
> hard coded value. The compiler will produce much better code in these
> cases.
>
> Also, maybe 'distro' people may want to make a 'hand-held' (Debian) or a
> 'router' (OpenWRT) distribution and they would only pick either 'Vybrid'
> or 'LayerScape'. However, if someone wants an 'every ARM under the
> sun', then the code still works. So, I think that the code is better
> setup for a subsequent patch set like this (or at least just a good).
>
> Especially, the stuff on the I/O swapping in the 'readl()' and
> 'writel()' is no longer needed; I think you can use the same function
> for both SOCs.
>
> > +#define __FTM_SWAP32(v) ((u32)(\
> > + (((u32)(v) & (u32)0x00ffUL) << 24) |\
> > + (((u32)(v) & (u32)0xff00UL) << 8) |\
> > + (((u32)(v) & (u32)0x00ffUL) >> 8) |\
> > + (((u32)(v) & (u32)0xff00UL) >> 24)))
> > +#define FTM_SWAP32(b, v) (b ? __FTM_SWAP32(v) : v)
>
> I think that there are macros that you could use here. For instance,
> '#include ' (powerpc and arm) has some assembler macros
> that are quite fast for swapping. If the kernel config has ARCH >= 6
> for ARM, then the very fast 'rev' instruction is used. If not, then a
> generic version is used as you have coded. The PowerPC (another
> possible future ARCH for QorIQ/Layerscape SOC?) always has inline
> assembler macros.
>
> So,
>
> + #include
> ...
> + #define FTM_SWAP32(b, v)(b ? __swab32(v) : v)
>
> might be better.
>
Yes.
I have removed the big-endian support temporarily, and will send followed
patches about this.
Thanks,
--
Best Regards,
Xiubo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: imx6q: Add missing esai_ahb clock to current clock tree
[Added Mike Turquette to Cc]
On Thu, Jan 09, 2014 at 11:04:59AM +0800, Nicolin Chen wrote:
> esai_ahb clock is derived from ahb and used to provide ESAI the capability of
> register accessing and FSYS clock source for I2S clocks dividing. Although the
> gate of this esai_ahb is duplicated with esai clock -- the baud clock, yet
> considering about the differences of their clock rates, it's quite essential
> to patch this missing clock.
>
[...]
> static struct clk *clk[clk_max];
> @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node
> *ccm_node)
> clk[ecspi5] = imx_clk_gate2("ecspi5","ecspi_root",
> base + 0x6c, 8);
> clk[enet] = imx_clk_gate2("enet", "ipg",
> base + 0x6c, 10);
> clk[esai] = imx_clk_gate2("esai", "esai_podf",
> base + 0x6c, 16);
> + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb",
> base + 0x6c, 16);
We have the situation here that a single bit controls two clocks. As
Shawn mentioned just using two gates on the same bit doesn't work
properly. Do we need a new basic clock type or expand the common gate
code somehow?
This situation happens from time to time and I haven't seen a solution
for this.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: imx6q: Add missing esai_ahb clock to current clock tree
On Thu, Jan 09, 2014 at 02:57:42PM +0800, Shawn Guo wrote:
> On Thu, Jan 09, 2014 at 11:49:41AM +0800, Nicolin Chen wrote:
> > On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > > > static struct clk *clk[clk_max];
> > > > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct
> > > > device_node *ccm_node)
> > > > clk[ecspi5] = imx_clk_gate2("ecspi5",
> > > > "ecspi_root",base + 0x6c, 8);
> > > > clk[enet] = imx_clk_gate2("enet", "ipg",
> > > > base + 0x6c, 10);
> > > > clk[esai] = imx_clk_gate2("esai", "esai_podf",
> > > > base + 0x6c, 16);
> > > > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb",
> > > > base + 0x6c, 16);
> > >
> > > Hmm, having two clocks operating on the same gate bit will get us
> > > problem in clock disabling. Clock enabling is fine, since either
> > > one who calls clk_enable() first will just set the gate bit. But in
> > > case that clk_enable() is called on both clocks, and then when either
> > > clock calls clk_disable(), the gate bit will be cleared and thus breaks
> > > the other one that might still be in use.
> >
> > Understood. But how could we handle this situation? The only way I can
> > figure
> > out is to make sure the driver open/close them at the same time, it's not a
> > perfect way though.
>
> Hmm, we generally leave the gate bit to the clock used to access
> register, because usually it's the first one to be on and the last one
> to be off.
Then we should attach CLK_IGNORE_UNUSED to clk[esai] since clk[esai_ahb] is
the clock used to access memory, shouldn't we?
Thank you.
Nicolin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 3/4] ASoC: fsl: Add VF610 simple audio card widgets driver.
> > This is the SGTL5000 codec based off-CODEC widgets supports. > > > > Signed-off-by: Xiubo Li > > --- > > sound/soc/fsl/Kconfig | 25 ++ > > sound/soc/fsl/Makefile| 3 +++ > > sound/soc/fsl/snd-soc-simple-card-vf610.c | 44 > +++ > > If we're needing to add explict code for a simple audio card that seems > to defeat the point of using the simple audio card - we may as well just > have an explicit machine driver. > IMHO, the simple audio card driver could fulfil most of machine driver's work. And will make some machine driver simpler and eaiser to code. Thanks, -- Best Regards, Xiubo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/4] ASoC: simple-card: add simple audio card widgets support
> > For many audio cards there need to add some off-CODEC widgets, and this
> > is hard to be supported by dts only, because maybe some widgets need one
> > or more call backs, such as wevent.
>
> The big question here would be why these widgets need to be added
>
For instance, from the SGTL5000 codec Spec:
The analog input block contains a stereo line input and a microphone input
with mic bias. Either input can be routed to the ADC. The line input can also
be configured to bypass the CODEC and be routed directly to the headphone
output.
And in the SGTL5000 codec driver there is one "Mic Bias" widget, and this
should be routed to one off-CODEC widget, like "Mic Jack"(the microphone input).
> the
> default thing is that all inputs and outputs are enabled so it can't be
> that and as you say callbacks are going to need to be added.
>
Some drivers may need like this:
SND_SOC_DAPM_PGA_E("Output Amp", SND_SOC_NOPM, 0, 0, NULL, 0,
XXX_output_amp_event, SND_SOC_DAPM_PRE_PMU |
SND_SOC_DAPM_POST_PMD),
?
> If this is used then it probably makes sense for the card to set the
> fully routed flag since one possible use is to disable unconnected pins
> on the CODEC.
>
> > +- simple-sudio-card,widgets: The name of the audio card
> > off-CODEC
> widgets.
>
> simple-audio-card. This also needs more documentation about what is
> supposed to be filled in here.
>
Yes, if needed.
> > +void
> > +asoc_simple_card_widgets_unregister(struct asoc_simple_card_widgets *comp)
>
> We always use snd_soc.
>
> One interesting thing here is that this is done separately to the card
> itself. Is there any actual dependency on the simple card, could this
> be made into a generic library that any machine driver could use? I can
> see other machines being able to make use of this.
No, has no dependency on the simple card.
Thanks,
--
Best Regards,
Xiubo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Drivers: hv: Implement the file copy service
On Wed, Jan 08, 2014 at 03:48:35PM -0800, K. Y. Srinivasan wrote:
> Implement the file copy service for Linux guests on Hyper-V. This permits the
> host to copy a file (over VMBUS) into the guest. This facility is part of
> "guest integration services" supported on the Windows platform.
> Here is a link that provides additional details on this functionality:
>
> http://technet.microsoft.com/en-us/library/dn464282.aspx
>
>
Is there no way we could implement file copying in user space?
> Signed-off-by: K. Y. Srinivasan
> ---
> drivers/hv/Makefile|2 +-
> drivers/hv/hv_fcopy.c | 451
>
> drivers/hv/hv_util.c | 10 +
> include/linux/hyperv.h | 60 ++
> tools/hv/hv_fcopy_daemon.c | 171 +
> 5 files changed, 693 insertions(+), 1 deletions(-)
> create mode 100644 drivers/hv/hv_fcopy.c
> create mode 100644 tools/hv/hv_fcopy_daemon.c
>
> diff --git a/drivers/hv/Makefile b/drivers/hv/Makefile
> index 0a74b56..5e4dfa4 100644
> --- a/drivers/hv/Makefile
> +++ b/drivers/hv/Makefile
> @@ -5,4 +5,4 @@ obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
> hv_vmbus-y := vmbus_drv.o \
>hv.o connection.o channel.o \
>channel_mgmt.o ring_buffer.o
> -hv_utils-y := hv_util.o hv_kvp.o hv_snapshot.o
> +hv_utils-y := hv_util.o hv_kvp.o hv_snapshot.o hv_fcopy.o
> diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
> new file mode 100644
> index 000..e44a112
> --- /dev/null
> +++ b/drivers/hv/hv_fcopy.c
> @@ -0,0 +1,451 @@
> +/*
> + * An implementation of file copy service.
> + *
> + * Copyright (C) 2014, Microsoft, Inc.
> + *
> + * Author : K. Y. Srinivasan
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation.
> + *
> + * 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, GOOD TITLE or
> + * NON INFRINGEMENT. See the GNU General Public License for more
> + * details.
> + *
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Use #include for better security.
> +
> +#define WIN8_SRV_MAJOR 1
> +#define WIN8_SRV_MINOR 1
> +#define WIN8_SRV_VERSION (WIN8_SRV_MAJOR << 16 | WIN8_SRV_MINOR)
> +
> +
> +
Extra blank line.
> +/*
> + * Global state maintained for transaction that is being processed.
> + * Note that only one transaction can be active at any point in time.
> + *
> + * This state is set when we receive a request from the host; we
> + * cleanup this state when the transaction is completed - when we respond
> + * to the host with our response.
> + */
> +
> +static struct {
> + bool active; /* transaction status - active or not */
> + int recv_len; /* number of bytes received. */
> + struct hv_fcopy_hdr *fcopy_msg; /* current message */
> + struct hv_start_fcopy message; /* sent to daemon */
> + struct vmbus_channel *recv_channel; /* chn we got the request */
> + u64 recv_req_id; /* request ID. */
> + void *fcopy_context; /* for the channel callback */
> + struct semaphore read_sema;
This is racy at the start. read_sema is supposed to be locked until
there is a file to be copied but it starts out unlocked and we unlock it
again at the start of a transaction.
Sending multiple files is also racy. The "active" flag is supposed to
serialize it but flags are not locks and they are not atomic. We can
queue up one request in the fcopy_context pointer but it's written in
a last added request overwrites the previous ones. It could overwrite
the current one as well if we got really unlucky.
> +} fcopy_transaction;
> +
> +
> +
Two extra newlines.
> +static dev_t fcopy_dev;
> +static bool daemon_died = false;
daemon_died is a write only variable.
> +static bool opened; /* currently device opened */
> +static struct task_struct *dtp; /* daemon task ptr */
> +
> +/*
> + * Before we can accept copy messages from the host, we need
> + * to handshake with the user level daemon. This state tracks
> + * if we are in the handshake phase.
> + */
> +static bool in_hand_shake = true;
> +
> +static void fcopy_send_data(void);
> +
> +
Extra blank lines throughout... Never use consecutive blank lines.
> +static void fcopy_respond_to_host(int error);
> +static void fcopy_work_func(struct work_struct *dummy);
> +
> +static DECLARE_DELAYED_WORK(fcopy_work, fcopy_work_func);
> +
> +static u8 *recv_buffer;
> +
> +static void fcopy_work_func(struct work_struct *dummy)
> +{
> + /*
> + * If the timer fires, the user-mode component has not responded;
> + * process the pending transaction.
> + */
> +
Re: [RFC] mm: show message when updating min_free_kbytes in thp
On Wed, Jan 08, 2014 at 11:16:11AM +0100, Michal Hocko wrote:
> On Wed 08-01-14 16:20:01, Han Pingtian wrote:
> > On Mon, Jan 06, 2014 at 05:46:04PM +0100, Michal Hocko wrote:
> > > On Sun 05-01-14 08:35:01, Han Pingtian wrote:
> > > [...]
> > > > From f4d085a880dfae7638b33c242554efb0afc0852b Mon Sep 17 00:00:00 2001
> > > > From: Han Pingtian
> > > > Date: Fri, 3 Jan 2014 11:10:49 +0800
> > > > Subject: [PATCH] mm: show message when raising min_free_kbytes in THP
> > > >
> > > > min_free_kbytes may be raised during THP's initialization. Sometimes,
> > > > this will change the value being set by user. Showing message will
> > > > clarify this confusion.
> > >
> > > I do not have anything against informing about changing value
> > > set by user but this will inform also when the default value is
> > > updated. Is this what you want? Don't you want to check against
> > > user_min_free_kbytes? (0 if not set by user)
> > >
> >
> > To use user_min_free_kbytes in mm/huge_memory.c, we need a
> >
> > extern int user_min_free_kbytes;
>
> The variable is not defined as static so you can use it outside of
> mm/page_alloc.c.
>
> > in somewhere? Where should we put it? I guess it is mm/internal.h,
> > right?
>
> I do not think this has to be globaly visible though. Why not just
> extern declaration in mm/huge_memory.c?
>
This is the new patch, please review. Thanks.
>From b8db4f157a17d6d8652cc9cff024a192c3ee0779 Mon Sep 17 00:00:00 2001
From: Han Pingtian
Date: Thu, 9 Jan 2014 15:24:26 +0800
Subject: [PATCH] mm: show message when raising min_free_kbytes in THP
min_free_kbytes may be raised during THP's initialization. Sometimes,
this will change the value being set by user. Showing message will
clarify this confusion.
Only show this message when changing the value set by user according to
Michal Hocko's suggestion.
Showing the old value of min_free_kbytes according to Dave Hansen's
suggestion. This will give user the chance to restore old value of
min_free_kbytes.
Signed-off-by: Han Pingtian
---
mm/huge_memory.c |9 -
mm/page_alloc.c |2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 7de1bf8..e0e4e29 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -100,6 +100,7 @@ static struct khugepaged_scan khugepaged_scan = {
.mm_head = LIST_HEAD_INIT(khugepaged_scan.mm_head),
};
+extern int user_min_free_kbytes;
static int set_recommended_min_free_kbytes(void)
{
@@ -130,8 +131,14 @@ static int set_recommended_min_free_kbytes(void)
(unsigned long) nr_free_buffer_pages() / 20);
recommended_min <<= (PAGE_SHIFT-10);
- if (recommended_min > min_free_kbytes)
+ if (recommended_min > min_free_kbytes) {
+ if (user_min_free_kbytes >= 0)
+ pr_info("raising min_free_kbytes from %d to %lu "
+ "to help transparent hugepage allocations\n",
+ min_free_kbytes, recommended_min);
+
min_free_kbytes = recommended_min;
+ }
setup_per_zone_wmarks();
return 0;
}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9ea62b2..a9dcfd8 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -205,7 +205,7 @@ static char * const zone_names[MAX_NR_ZONES] = {
};
int min_free_kbytes = 1024;
-int user_min_free_kbytes;
+int user_min_free_kbytes = -1;
static unsigned long __meminitdata nr_kernel_pages;
static unsigned long __meminitdata nr_all_pages;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Revert "intel_idle: mark states tables with __initdata tag"
This reverts commit 9d046ccb98085f1d437585f84748c783a04ba240.
Commit 9d046ccb98085 marks all state tables with __initdata, but
the state table may be accessed when doing CPU online, which then
causing system crash as below:
[ 204.188841] BUG: unable to handle kernel paging request at 8227cce8
[ 204.196844] IP: [] intel_idle_cpu_init+0x40/0x130
[ 204.203996] PGD 1e11067 PUD 1e12063 PMD 455859063 PTE 8227c062
[ 204.211638] Oops: [#1] SMP DEBUG_PAGEALLOC
[ 204.216975] Modules linked in: x86_pkg_temp_thermal intel_powerclamp
coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd gpio_ich
microcode joydev sb_edac edac_core ipmi_si lpc_ich ipmi_msghandler lp tpm_tis
parport wmi mac_hid acpi_pad hid_generic ixgbe isci usbhid dca hid libsas ptp
ahci libahci scsi_transport_sas megaraid_sas pps_core mdio
[ 204.262815] CPU: 11 PID: 1489 Comm: bash Not tainted 3.13.0-rc7+ #48
[ 204.269993] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BRIVTIN1.86B.0047.L09.1312061514 12/06/2013
[ 204.281646] task: 8804303a24a0 ti: 880440fac000 task.ti:
880440fac000
[ 204.290311] RIP: 0010:[] []
intel_idle_cpu_init+0x40/0x130
[ 204.300184] RSP: 0018:880440fadd28 EFLAGS: 00010286
[ 204.306192] RAX: 8227cca0 RBX: e8fff1a03400 RCX: 0007
[ 204.314244] RDX: 88045f40 RSI: 0009 RDI: 1120
[ 204.322296] RBP: 880440fadd38 R08: R09: 0001
[ 204.330411] R10: 0001 R11: R12: 001e
[ 204.338482] R13: ffdb R14: 0001 R15:
[ 204.346743] FS: 7f64f7b0c740() GS:88045ce0()
knlGS:
[ 204.355919] CS: 0010 DS: ES: CR0: 80050033
[ 204.362449] CR2: 8227cce8 CR3: 000444ab CR4: 001407e0
[ 204.370520] Stack:
[ 204.372853] 001e 81f10240 880440fadd50
814aa307
[ 204.381519] 81ea80e0 880440fadda0 8185a230
[ 204.390196] 001e 0002 0002
[ 204.398856] Call Trace:
[ 204.401683] [] cpu_hotplug_notify+0x57/0x70
[ 204.408638] [] notifier_call_chain+0x100/0x150
[ 204.415553] [] __raw_notifier_call_chain+0xe/0x10
[ 204.422772] [] cpu_notify+0x23/0x50
[ 204.428616] [] _cpu_up+0x132/0x1a0
[ 204.434361] [] cpu_up+0x7d/0xa0
[ 204.439819] [] cpu_subsys_online+0x3c/0x90
[ 204.446345] [] device_online+0x45/0xa0
[ 204.452471] [] online_store+0x4e/0x80
[ 204.458511] [] dev_attr_store+0x18/0x30
[ 204.464744] [] sysfs_write_file+0x151/0x1c0
[ 204.471681] [] vfs_write+0xe1/0x160
[ 204.477524] [] SyS_write+0x4c/0x90
[ 204.483270] [] system_call_fastpath+0x1a/0x1f
[ 204.490081] Code: 41 54 41 89 fc 8b 3d 48 25 85 01 53 48 8b 1d 30 25 85 01
48 03 1c c5 40 90 fb 81 48 8b 05 19 25 85 01 c7 43 0c 01 00 00 00 66 90 <48> 83
78 48 00 74 4f 41 83 c0 01 41 39 f0 7e 10 48 c7 c7 38 79
[ 204.515723] RIP [] intel_idle_cpu_init+0x40/0x130
[ 204.522996] RSP
[ 204.526976] CR2: 8227cce8
[ 204.530766] ---[ end trace 336f56cc3d1cfc8c ]---
Signed-off-by: Jiang Liu
Cc: # 3.12+
---
drivers/idle/intel_idle.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index f80b700..6f456f0 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -123,7 +123,7 @@ static struct cpuidle_state *cpuidle_state_table;
* which is also the index into the MWAIT hint array.
* Thus C0 is a dummy.
*/
-static struct cpuidle_state nehalem_cstates[] __initdata = {
+static struct cpuidle_state nehalem_cstates[] = {
{
.name = "C1-NHM",
.desc = "MWAIT 0x00",
@@ -156,7 +156,7 @@ static struct cpuidle_state nehalem_cstates[] __initdata = {
.enter = NULL }
};
-static struct cpuidle_state snb_cstates[] __initdata = {
+static struct cpuidle_state snb_cstates[] = {
{
.name = "C1-SNB",
.desc = "MWAIT 0x00",
@@ -196,7 +196,7 @@ static struct cpuidle_state snb_cstates[] __initdata = {
.enter = NULL }
};
-static struct cpuidle_state ivb_cstates[] __initdata = {
+static struct cpuidle_state ivb_cstates[] = {
{
.name = "C1-IVB",
.desc = "MWAIT 0x00",
@@ -236,7 +236,7 @@ static struct cpuidle_state ivb_cstates[] __initdata = {
.enter = NULL }
};
-static struct cpuidle_state hsw_cstates[] __initdata = {
+static struct cpuidle_state hsw_cstates[] = {
{
.name = "C1-HSW",
.desc = "MWAIT 0x00",
@@ -297,7 +297,7 @@ static struct cpuidle_state hsw_cstates[] __initdata = {
.enter = NULL }
};
-static struct cpuidle_state atom_cstates[]
[PATCH 2/2] intel_idle: close avn_cstates array with correct marker
Close avn_cstates array with correct marker to avoid overflow
in function intel_idle_cpu_init().
Signed-off-by: Jiang Liu
Cc: # 3.13
---
drivers/idle/intel_idle.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 6f456f0..797ed29 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -329,7 +329,7 @@ static struct cpuidle_state atom_cstates[] = {
{
.enter = NULL }
};
-static struct cpuidle_state avn_cstates[] __initdata = {
+static struct cpuidle_state avn_cstates[] = {
{
.name = "C1-AVN",
.desc = "MWAIT 0x00",
@@ -344,6 +344,8 @@ static struct cpuidle_state avn_cstates[] __initdata = {
.exit_latency = 15,
.target_residency = 45,
.enter = _idle },
+ {
+ .enter = NULL }
};
/**
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v12 0/7] cpufreq:boost: CPU Boost mode support
Hi Rafael, Zhang, > On Tuesday, January 07, 2014 07:58:24 AM Lukasz Majewski wrote: > > Hi Rafael, > > Hi, > > > > This patch series introduces support for CPU overclocking > > > technique called Boost. > > > > > > It is a follow up of a LAB governor proposal. Boost is a LAB > > > component: > > > http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq > > > > > > Boost unifies hardware based solution (e.g. Intel Nehalem) with > > > software oriented one (like the one done at Exynos). > > > For this reason cpufreq/freq_table code has been reorganized to > > > include common code. > > > > > > Important design decisions: > > > - Boost related code is compiled-in unconditionally to cpufreq > > > core and disabled by default. The cpufreq_driver is responsibile > > > for setting boost_supported flag and providing set_boost > > > callback(if HW support is needed). For software managed boost, > > > special Kconfig flag - CONFIG_CPU_FREQ_BOOST_SW has been defined. > > > It will be selected only when a target platform has thermal > > > framework properly configured. > > > > > > - struct cpufreq_driver has been extended with boost related > > > fields: -- boost_supported - when driver supports boosting > > > -- boost_enabled - boost state > > > -- set_boost - callback to function, which is necessary to > > >enable/disable boost > > > > > > - Boost sysfs attribute (/sys/devices/system/cpu/cpufreq/boost) is > > > visible _only_ when cpufreq driver supports Boost. > > > > > > - No special spin_lock for Boost was created. The one from cpufreq > > > core was reused. > > > > > > - The Boost code doesn't rely on any policy. When boost state is > > > changed, then the policy list is iterated and proper adjustements > > > are done. > > > > > > - To improve safety level, the thermal framework is also extended > > > to disable software boosting, when thermal trip point is reached. > > > After cooling down the boost can be enabled again. This emulates > > > behaviour similar to HW managed boost (like x86) > > > > > > Tested at HW: > > >Exynos 4412 3.13-rc4 Linux > > >Intel Core i7-3770 3.13-rc4 Linux > > > > > > Above patches were posted on top of kernel_pm/bleeding-edge > > > (SHA1: bd0f3a5d9dce48a917ce1f1047534d79c725149) > > > > > > Lukasz Majewski (7): > > > cpufreq: Add boost frequency support in core > > > cpufreq:acpi:x86: Adjust the acpi-cpufreq.c code to work with > > > common boost solution > > > cpufreq:boost:Kconfig: Provide support for software managed > > > BOOST cpufreq:exynos:Extend Exynos cpufreq driver to support boost > > > framework > > > Documentation:cpufreq:boost: Update BOOST documentation > > > cpufreq:exynos4x12: Change L0 driver data to CPUFREQ_BOOST_FREQ > > > thermal:exynos:boost: Automatic enable/disable of BOOST feature > > > (at Exynos4412) > > > > > > Documentation/cpu-freq/boost.txt | 26 +++ > > > drivers/cpufreq/Kconfig |4 + > > > drivers/cpufreq/Kconfig.arm | 15 > > > drivers/cpufreq/acpi-cpufreq.c| 86 > > > +++-- drivers/cpufreq/cpufreq.c | > > > 118 - > > > drivers/cpufreq/exynos-cpufreq.c |3 + > > > drivers/cpufreq/exynos4x12-cpufreq.c |2 +- > > > drivers/cpufreq/freq_table.c | 56 -- > > > drivers/thermal/samsung/exynos_tmu_data.c | 12 +-- > > > include/linux/cpufreq.h | 24 ++ 10 files > > > changed, 261 insertions(+), 85 deletions(-) > > > > > > > A gentle ping about BOOST patches. > > > > Its been already acked by Viresh and Eduardo. > > > > It applies on kernel_pm/bleeding_edge SHA1: > > 4836deb72c5e2a9af0cb2129c1149783a26d99ab > > It looks like Rui is still looking into this. > > Rui, are you fine with this series? I'd really appreciate Ack from Rui on this patch series. However, after Rui's comments on v9, I've completely removed the BOOST code from thermal core. Since the v10, I've only adjusted default data for Exynos SoC. This approach has been finally accepted by Eduardo (who is responsible for this part of the thermal subsystem) on the v12. > > Rafael > -- Best regards, Lukasz Majewski Samsung R Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
On Wed, Jan 08, 2014 at 11:05:42AM -0800, John Fastabend wrote:
> [...]
>
> >>>OK I think I'm finally putting all the pieces together thanks.
> >>>
> >>>Do you know why macvtap is setting dev->tx_queue_len by default? If you
> >>>zero this then the noqueue_qdisc is used and the q->enqueue check in
> >>>dev_queue_xmit will fail.
> >>
> >>It was introduced in commit 8a35747a5d13b99e076b0222729e0caa48cb69b6
> >>("macvtap: Limit packet queue length") to limit the length of socket
> >>receive queue of macvtap. But I'm not sure whether the qdisc is a
> >>byproduct of this commit, maybe we can switch to use another name
> >>instead of just reuse dev->tx_queue_length.
> >
> >You mean tx_queue_len really, right?
> >
> >Problem is tx_queue_len can be accessed using netlink sysfs or ioctl,
> >so if someone uses these to control or check the # of packets that
> >can be queued by device, this will break.
> >
> >How about adding ndo_set_tx_queue_len then?
> >
> >At some point we wanted to decouple queue length from tx_queue_length
> >for tun as well, so that would be benefitial there as well.
>
> On the receive side we need to limit the receive queue and the
> dev->tx_queue_len value was used to do this.
>
> However on the tx side when dev->tx_queue_len is set the default
> qdisc pfifo_fast or mq is used depending on if there is multiqueue
> or not. Unless the user specifies some numtxqueues when creating
> the macvtap device then it will be a single queue device and use
> the pfifo_fast qdisc.
>
> This is the default behaviour users could zero txqueuelen when
> they create the device because it is a stacked device with
> NETIF_F_LLTX using the lower devices qdisc makes sense but this
> would appear (from code inspection) to break macvtap_forward()?
>
> if (skb_queue_len(>sk.sk_receive_queue) >= dev->tx_queue_len)
> goto drop;
>
> I'm not sure any of this is a problem other than its a bit
> confusing to overload tx_queue_len for the rx_queue_len but the
> precedent has been there for sometime.
So how about ndo ops to access tx_queue_len then?
This way we can set tx_queue_len to 0 and use some
other field to store the rx_queue_len without users noticing.
Along the lines of the below (it's a partial patch just
to give you the idea):
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index 5b7d0e1..e526b46 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -167,7 +167,10 @@ static int dev_ifsioc_locked(struct net *net, struct ifreq
*ifr, unsigned int cm
return 0;
case SIOCGIFTXQLEN:
- ifr->ifr_qlen = dev->tx_queue_len;
+ if (dev->netdev_ops->ndo_get_tx_queue_len)
+ ifr->ifr_qlen =
dev->netdev_ops->ndo_get_tx_queue_len(dev);
+ else
+ ifr->ifr_qlen = dev->tx_queue_len;
return 0;
default:
@@ -296,7 +299,10 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr,
unsigned int cmd)
case SIOCSIFTXQLEN:
if (ifr->ifr_qlen < 0)
return -EINVAL;
- dev->tx_queue_len = ifr->ifr_qlen;
+ if (dev->netdev_ops->ndo_set_tx_queue_len)
+ dev->netdev_ops->ndo_set_tx_queue_len(dev,
ifr->ifr_qlen);
+ else
+ dev->tx_queue_len = ifr->ifr_qlen;
return 0;
case SIOCSIFNAME:
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index d954b56..f2fd9d5 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -280,10 +280,31 @@ NETDEVICE_SHOW_RW(flags, fmt_hex);
static int change_tx_queue_len(struct net_device *net, unsigned long new_len)
{
- net->tx_queue_len = new_len;
+ if (dev->netdev_ops->ndo_set_tx_queue_len)
+ dev->netdev_ops->ndo_set_tx_queue_len(dev, new_len);
+ else
+ dev->tx_queue_len = new_len;
return 0;
}
+static ssize_t format_tx_queue_len(const struct net_device *net, char *buf)
+{
+ unsigned long tx_queue_len;
+
+ if (dev->netdev_ops->ndo_get_tx_queue_len)
+ tx_queue_len = dev->netdev_ops->ndo_get_tx_queue_len(dev);
+ else
+ tx_queue_len = dev->tx_queue_len;
+
+ return sprintf(buf, fmt_ulong, tx_queue_len);
+}
+
+static ssize_t tx_queue_len_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ return netdev_show(dev, attr, buf, format_tx_queue_len);
+}
+
static ssize_t tx_queue_len_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
@@ -293,7 +314,7 @@ static ssize_t tx_queue_len_store(struct device *dev,
return netdev_store(dev, attr, buf, len, change_tx_queue_len);
}
-NETDEVICE_SHOW_RW(tx_queue_len, fmt_ulong);
+DEVICE_ATTR_RW(tx_queue_len);
static ssize_t ifalias_store(struct device *dev,
Re: possible regression on 3.13 when calling flush_dcache_page
On Mon, Jan 06, 2014 at 10:34:09AM +0100, Ludovic Desroches wrote: > On Mon, Jan 06, 2014 at 09:26:48AM +0900, Joonsoo Kim wrote: > > On Fri, Jan 03, 2014 at 03:54:04PM +0100, Ludovic Desroches wrote: > > > Hi, > > > > > > On Tue, Dec 24, 2013 at 03:38:37PM +0900, Joonsoo Kim wrote: > > > > > > [...] > > > > > > > > > > > > I think that this commit may not introduce a bug. This patch > > > > > > > > > remove one > > > > > > > > > variable on slab management structure and replace variable > > > > > > > > > name. So there > > > > > > > > > is no functional change. > > > > > > You are right, the commit given by git bisect was not the good one... > > > Since I removed other patches done on top of it, I thought it really was > > > this one but in fact it is 8456a64. > > > > Okay. It seems more reasonable to me. > > I guess that this is the same issue with following link. > > http://lkml.org/lkml/2014/1/4/81 > > > > And, perhaps, that patch solves your problem. But I'm not sure that it is > > the > > best solution for this problem. I should discuss with slab maintainers. > > Yes this patch solves my problem. > > > > > I will think about this problem more deeply and report the solution to you > > as soon as possible. > > Ok thanks. > Hello, That patch will be merged through Andrew's tree. Use it to fix your problem :) Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nfsd: check passed socket's net matches NFSd superblock's one
04.01.2014 02:22, J. Bruce Fields пишет: On Mon, Dec 30, 2013 at 05:23:59PM +0300, Stanislav Kinsbursky wrote: There could be a case, when NFSd file system is mounted in network, different to socket's one, like below: "ip netns exec" creates new network and mount namespace, which duplicates NFSd mount point, created in init_net context. And thus NFS server stop in nested network context leads to RPCBIND client destruction in init_net. Then, on NFSd start in nested network context, rpc.nfsd process creates socket in nested net and passes it into "write_ports", which leads to RPCBIND sockets creation in init_net context because of the same reason (NFSd monut point was created in init_net context). An attempt to register passed socket in nested net leads to panic, because no RPCBIND client present in nexted network namespace. So it's the attempt to use a NULL ->rpcb_local_clnt4? Correct. -- Best regards, Stanislav Kinsbursky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the sh tree with the tree
On Sun, Jan 5, 2014 at 5:13 PM, Stephen Rothwell wrote:
> Hi Paul,
>
> Today's linux-next merge of the sh tree got conflicts in
> drivers/tty/serial/sh-sci.c and include/linux/serial_sci.h between
> commits 8fb9631c517b ("serial: sh-sci: Sort headers alphabetically"),
> 20bdcab8268c ("serial: sh-sci: Add OF support") and probably others from
> the arm-soc tree and commits ada80ee7fa60 ("serial: sh-sci: Add OF
> support") and b19ef75c56e9 ("serial: sh-sci: OF definitions need
> linux/of.h") from the sh tree.
>
> The arm-soc tree version is dated much more recently than
> the sh tree version and conflicts badly, so for today I have just dropped
> the sh tree (everything in there was committed before April 2013). Please
> figure this out.
The request to merge the sh code came through Simon with claimed
agreement from SH maintainers to do so -- I didn't verify this since
they have in the past been well-coordinated. Simon?
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] tty/serial: at91: disable uart timer at start of shutdown
Just to sumarize the bug after poking before the patch: systemd calls open/close on /dev/ttyS0 per line atmel_shutdown executes on close uart_timer_callback may fire during shutdown before timer is killed tasklet gets scheduled after tasklet_kill atmel_shutdown returns back to uart_close dice roll: if the tasklet executes before uart_close kills the tty references, the kernel is fine <--- I saw this happening more often than panics, around once every 3 resets if the tasklet executes after uart_close kills the tty references, it panics I tested the patch by old fashion way of manual board resets with a total of 70 resets each on two individual SAMA5D34-EK boards I have in my possession programmed with the same patched kernel image and rootfs. They did not panic once with the patch applied. Typically before the patch the panic would occur around once every 10 resets if not more often to the point it occured for 4 resets straight. I have been trying to automate the testing, even If I make sure nothing is using ttyS0 and then run a program that spams open() writev() and close() (systemd uses the syscalls) to print messages, it will never panic so I'm possibly misunderstanding how the driver startup/shutdown ops get triggered(which should just be open/close respectively) or variable length of messages from systemd and timing between messages contributes to being unlucky and having the timer fire at the wrong time. But from manual testing I'm pretty confident the bug is fixed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/7] mm/isolation: remove invalid check condition
test_page_isolated() checks stability of pages. It checks two conditions,
one is that the page is on isolate migratetype and the other is that
the page is on the buddy and the isolate freelist. With satisfying
these two conditions, we can determine that the page is stable and then
go forward.
__test_page_isolated_in_pageblock() is one of the main functions for this
test. In that function, if it meets the page with page_count 0 and
isolate migratetype, it decides that this page is stable. But this is not
true, because there is possiblity that this kind of page is on the pcp
and then it can be allocated by other users even though we hold the zone
lock. So removing this check.
Signed-off-by: Joonsoo Kim
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index d1473b2..534fb3a 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -199,9 +199,6 @@ __test_page_isolated_in_pageblock(unsigned long pfn,
unsigned long end_pfn,
}
pfn += 1 << page_order(page);
}
- else if (page_count(page) == 0 &&
- get_freepage_migratetype(page) == MIGRATE_ISOLATE)
- pfn += 1;
else if (skip_hwpoisoned_pages && PageHWPoison(page)) {
/*
* The HWPoisoned page may be not in buddy
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/7] mm/page_alloc: don't merge MIGRATE_(CMA|ISOLATE) pages on buddy
If (MAX_ORDER-1) is greater than pageblock order, there is a possibility
to merge different migratetype pages and to be linked in unintended
freelist.
While I test CMA, CMA pages are merged and linked into MOVABLE freelist
by above issue and then, the pages change their migratetype to UNMOVABLE by
try_to_steal_freepages(). After that, CMA to this region always fail.
To prevent this, we should not merge the page on MIGRATE_(CMA|ISOLATE)
freelist.
Signed-off-by: Joonsoo Kim
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2548b42..ea99cee 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -581,6 +581,15 @@ static inline void __free_one_page(struct page *page,
__mod_zone_freepage_state(zone, 1 << order,
migratetype);
} else {
+ int buddy_mt = get_buddy_migratetype(buddy);
+
+ /* We don't want to merge cma, isolate pages */
+ if (unlikely(order >= pageblock_order) &&
+ migratetype != buddy_mt &&
+ (migratetype >= MIGRATE_PCPTYPES ||
+ buddy_mt >= MIGRATE_PCPTYPES)) {
+ break;
+ }
list_del(>lru);
zone->free_area[order].nr_free--;
rmv_page_order(buddy);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] mm/page_alloc: store freelist migratetype to the page on buddy properly
To maintain freelist migratetype information on buddy pages, migratetype
should be set again whenever the page order is changed. set_page_order()
is the best place to do, because it is called whenever the page order is
changed, so this patch adds set_buddy_migratetype() to set_page_order().
And this patch makes set/get_buddy_migratetype() only enabled if it is
really needed, because it has some overhead.
Signed-off-by: Joonsoo Kim
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2733e0b..046e09f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -258,6 +258,12 @@ struct inode;
#define set_page_private(page, v) ((page)->private = (v))
/*
+ * This is for tracking the type of the list on buddy.
+ * It imposes some performance overhead to the buddy allocator,
+ * so we make it enabled only if it is needed.
+ */
+#if defined(CONFIG_MEMORY_ISOLATION) || defined(CONFIG_CMA)
+/*
* It's valid only if the page is on buddy. It represents
* which freelist the page is linked.
*/
@@ -270,6 +276,10 @@ static inline int get_buddy_migratetype(struct page *page)
{
return page->index;
}
+#else
+static inline void set_buddy_migratetype(struct page *page, int migratetype) {}
+static inline int get_buddy_migratetype(struct page *page) { return 0; }
+#endif
/*
* It's valid only if the page is on pcp list. It represents
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c9e6622..2548b42 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -446,9 +446,11 @@ static inline void set_page_guard_flag(struct page *page)
{ }
static inline void clear_page_guard_flag(struct page *page) { }
#endif
-static inline void set_page_order(struct page *page, int order)
+static inline void set_page_order(struct page *page, int order,
+ int migratetype)
{
set_page_private(page, order);
+ set_buddy_migratetype(page, migratetype);
__SetPageBuddy(page);
}
@@ -588,7 +590,7 @@ static inline void __free_one_page(struct page *page,
page_idx = combined_idx;
order++;
}
- set_page_order(page, order);
+ set_page_order(page, order, migratetype);
/*
* If this is not the largest possible page, check if the buddy
@@ -745,7 +747,6 @@ static void __free_pages_ok(struct page *page, unsigned int
order)
local_irq_save(flags);
__count_vm_events(PGFREE, 1 << order);
migratetype = get_pageblock_migratetype(page);
- set_buddy_migratetype(page, migratetype);
free_one_page(page_zone(page), page, order, migratetype);
local_irq_restore(flags);
}
@@ -834,7 +835,7 @@ static inline void expand(struct zone *zone, struct page
*page,
#endif
list_add([size].lru, >free_list[migratetype]);
area->nr_free++;
- set_page_order([size], high);
+ set_page_order([size], high, migratetype);
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] mm/cma: fix cma free page accounting
Cma pages can be allocated by not only order 0 request but also high order
request. So, we should consider to account free cma page in the both
places.
Signed-off-by: Joonsoo Kim
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b36aa5a..1489c301 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1091,6 +1091,12 @@ __rmqueue_fallback(struct zone *zone, int order, int
start_migratetype)
start_migratetype,
migratetype);
+ /* CMA pages cannot be stolen */
+ if (is_migrate_cma(migratetype)) {
+ __mod_zone_page_state(zone,
+ NR_FREE_CMA_PAGES, -(1 << order));
+ }
+
/* Remove the page from the freelists */
list_del(>lru);
rmv_page_order(page);
@@ -1175,9 +1181,6 @@ static int rmqueue_bulk(struct zone *zone, unsigned int
order,
}
set_freepage_migratetype(page, mt);
list = >lru;
- if (is_migrate_cma(mt))
- __mod_zone_page_state(zone, NR_FREE_CMA_PAGES,
- -(1 << order));
}
__mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));
spin_unlock(>lock);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] mm/page_alloc: separate interface to set/get migratetype of freepage
Currently, we use (set/get)_freepage_migratetype in two use cases.
One is to know the buddy list where this page will be linked and
the other is to know the buddy list where this page is linked now.
But, we should deal these two use cases differently, because information
isn't sufficient for the second use case and properly setting this
information needs some overhead. Whenever the page is merged or split
in buddy, this information isn't properly re-assigned and it may not
have enough information for the second use case.
This patch just separates interface, so there is no functional change.
Following patch will do further steps about this issue.
Signed-off-by: Joonsoo Kim
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 3552717..2733e0b 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -257,14 +257,31 @@ struct inode;
#define page_private(page) ((page)->private)
#define set_page_private(page, v) ((page)->private = (v))
-/* It's valid only if the page is free path or free_list */
-static inline void set_freepage_migratetype(struct page *page, int migratetype)
+/*
+ * It's valid only if the page is on buddy. It represents
+ * which freelist the page is linked.
+ */
+static inline void set_buddy_migratetype(struct page *page, int migratetype)
+{
+ page->index = migratetype;
+}
+
+static inline int get_buddy_migratetype(struct page *page)
+{
+ return page->index;
+}
+
+/*
+ * It's valid only if the page is on pcp list. It represents
+ * which freelist the page should go on buddy.
+ */
+static inline void set_pcp_migratetype(struct page *page, int migratetype)
{
page->index = migratetype;
}
-/* It's valid only if the page is free path or free_list */
-static inline int get_freepage_migratetype(struct page *page)
+/* It's valid only if the page is on pcp list */
+static inline int get_pcp_migratetype(struct page *page)
{
return page->index;
}
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4913829..c9e6622 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -681,7 +681,7 @@ static void free_pcppages_bulk(struct zone *zone, int count,
page = list_entry(list->prev, struct page, lru);
/* must delete as __free_one_page list manipulates */
list_del(>lru);
- mt = get_freepage_migratetype(page);
+ mt = get_pcp_migratetype(page);
/* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
__free_one_page(page, zone, 0, mt);
trace_mm_page_pcpu_drain(page, 0, mt);
@@ -745,7 +745,7 @@ static void __free_pages_ok(struct page *page, unsigned int
order)
local_irq_save(flags);
__count_vm_events(PGFREE, 1 << order);
migratetype = get_pageblock_migratetype(page);
- set_freepage_migratetype(page, migratetype);
+ set_buddy_migratetype(page, migratetype);
free_one_page(page_zone(page), page, order, migratetype);
local_irq_restore(flags);
}
@@ -903,7 +903,7 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned
int order,
rmv_page_order(page);
area->nr_free--;
expand(zone, page, order, current_order, area, migratetype);
- set_freepage_migratetype(page, migratetype);
+ set_pcp_migratetype(page, migratetype);
return page;
}
@@ -971,7 +971,7 @@ int move_freepages(struct zone *zone,
order = page_order(page);
list_move(>lru,
>free_area[order].free_list[migratetype]);
- set_freepage_migratetype(page, migratetype);
+ set_buddy_migratetype(page, migratetype);
page += 1 << order;
pages_moved += 1 << order;
}
@@ -1094,12 +1094,11 @@ __rmqueue_fallback(struct zone *zone, int order, int
start_migratetype)
/* CMA pages cannot be stolen */
if (is_migrate_cma(migratetype)) {
- set_freepage_migratetype(page, migratetype);
+ set_pcp_migratetype(page, migratetype);
__mod_zone_page_state(zone,
NR_FREE_CMA_PAGES, -(1 << order));
} else {
- set_freepage_migratetype(page,
- start_migratetype);
+ set_pcp_migratetype(page, start_migratetype);
}
/* Remove the page from the freelists */
@@ -1346,7 +1345,7 @@ void free_hot_cold_page(struct page *page, int cold)
return;
migratetype = get_pageblock_migratetype(page);
- set_freepage_migratetype(page, migratetype);
+ set_pcp_migratetype(page, migratetype);
[PATCH 3/7] mm/page_alloc: move set_freepage_migratetype() to better place
set_freepage_migratetype() inform us of the buddy freelist where
the page should be linked when it goes to buddy freelist.
Now, it has done in rmqueue_bulk() so that we should call
get_pageblock_migratetype() to know it's migratetype exactly if
CONFIG_CMA is enabled. That function has some overhead so that
removing it is preferable.
To remove it, we move set_freepage_migratetype() to __rmqueue_fallback()
and __rmqueue_smallest(). In those functions, we can know migratetype
easily so that we don't need to call get_pageblock_migratetype().
Removing is_migrate_isolate() is safe since what we want to ensure is
that the page from cma will not go to other migratetype freelist.
Signed-off-by: Joonsoo Kim
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 1489c301..4913829 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -903,6 +903,7 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned
int order,
rmv_page_order(page);
area->nr_free--;
expand(zone, page, order, current_order, area, migratetype);
+ set_freepage_migratetype(page, migratetype);
return page;
}
@@ -1093,8 +1094,12 @@ __rmqueue_fallback(struct zone *zone, int order, int
start_migratetype)
/* CMA pages cannot be stolen */
if (is_migrate_cma(migratetype)) {
+ set_freepage_migratetype(page, migratetype);
__mod_zone_page_state(zone,
NR_FREE_CMA_PAGES, -(1 << order));
+ } else {
+ set_freepage_migratetype(page,
+ start_migratetype);
}
/* Remove the page from the freelists */
@@ -1153,7 +1158,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int
order,
unsigned long count, struct list_head *list,
int migratetype, int cold)
{
- int mt = migratetype, i;
+ int i;
spin_lock(>lock);
for (i = 0; i < count; ++i) {
@@ -1174,12 +1179,6 @@ static int rmqueue_bulk(struct zone *zone, unsigned int
order,
list_add(>lru, list);
else
list_add_tail(>lru, list);
- if (IS_ENABLED(CONFIG_CMA)) {
- mt = get_pageblock_migratetype(page);
- if (!is_migrate_cma(mt) && !is_migrate_isolate(mt))
- mt = migratetype;
- }
- set_freepage_migratetype(page, mt);
list = >lru;
}
__mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] mm/page_alloc: synchronize get/set pageblock
Now get/set pageblock is done without any syncronization. Therefore
there is race condition and migratetype can be unintended value.
Sometime we move some pageblocks from one migratetype to the other
type, and, at the sametime, some page in this pageblock could be
freed. In this case, we can get totally unintended value,
since get/set pageblock don't get/set atomically. Instead, it is
accessed in bit unit.
Since set pageblock isn't used frequently rather than get pageblock,
I think that seqlock is proper method to synchronize it. This type
of lock has minimum overhead if there are a lot of readers and few
of writers. So it fits to this situation.
Signed-off-by: Joonsoo Kim
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index bd791e4..feaa607 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -79,6 +79,7 @@ static inline int get_pageblock_migratetype(struct page *page)
{
return get_pageblock_flags_group(page, PB_migrate, PB_migrate_end);
}
+void set_pageblock_migratetype(struct page *page, int migratetype);
struct free_area {
struct list_headfree_list[MIGRATE_TYPES];
@@ -367,6 +368,7 @@ struct zone {
#endif
struct free_areafree_area[MAX_ORDER];
+ seqlock_t pageblock_seqlock;
#ifndef CONFIG_SPARSEMEM
/*
* Flags for a pageblock_nr_pages block. See pageblock-flags.h.
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 3fff8e7..58e2a89 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -23,7 +23,6 @@ static inline bool is_migrate_isolate(int migratetype)
bool has_unmovable_pages(struct zone *zone, struct page *page, int count,
bool skip_hwpoisoned_pages);
-void set_pageblock_migratetype(struct page *page, int migratetype);
int move_freepages_block(struct zone *zone, struct page *page,
int migratetype);
int move_freepages(struct zone *zone,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5248fe0..b36aa5a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4788,6 +4788,7 @@ static void __paginginit free_area_init_core(struct
pglist_data *pgdat,
spin_lock_init(>lock);
spin_lock_init(>lru_lock);
zone_seqlock_init(zone);
+ seqlock_init(>pageblock_seqlock);
zone->zone_pgdat = pgdat;
zone_pcp_init(zone);
@@ -5927,15 +5928,19 @@ unsigned long get_pageblock_flags_group(struct page
*page,
unsigned long pfn, bitidx;
unsigned long flags = 0;
unsigned long value = 1;
+ unsigned int seq;
zone = page_zone(page);
pfn = page_to_pfn(page);
bitmap = get_pageblock_bitmap(zone, pfn);
bitidx = pfn_to_bitidx(zone, pfn);
- for (; start_bitidx <= end_bitidx; start_bitidx++, value <<= 1)
- if (test_bit(bitidx + start_bitidx, bitmap))
- flags |= value;
+ do {
+ seq = read_seqbegin(>pageblock_seqlock);
+ for (; start_bitidx <= end_bitidx; start_bitidx++, value <<= 1)
+ if (test_bit(bitidx + start_bitidx, bitmap))
+ flags |= value;
+ } while (read_seqretry(>pageblock_seqlock, seq));
return flags;
}
@@ -5954,6 +5959,7 @@ void set_pageblock_flags_group(struct page *page,
unsigned long flags,
unsigned long *bitmap;
unsigned long pfn, bitidx;
unsigned long value = 1;
+ unsigned long irq_flags;
zone = page_zone(page);
pfn = page_to_pfn(page);
@@ -5961,11 +5967,13 @@ void set_pageblock_flags_group(struct page *page,
unsigned long flags,
bitidx = pfn_to_bitidx(zone, pfn);
VM_BUG_ON(!zone_spans_pfn(zone, pfn));
+ write_seqlock_irqsave(>pageblock_seqlock, irq_flags);
for (; start_bitidx <= end_bitidx; start_bitidx++, value <<= 1)
if (flags & value)
__set_bit(bitidx + start_bitidx, bitmap);
else
__clear_bit(bitidx + start_bitidx, bitmap);
+ write_sequnlock_irqrestore(>pageblock_seqlock, irq_flags);
}
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/7] improve robustness on handling migratetype
Hello, I found some weaknesses on handling migratetype during code review and testing CMA. First, we don't have any synchronization method on get/set pageblock migratetype. When we change migratetype, we hold the zone lock. So writer-writer race doesn't exist. But while someone changes migratetype, others can get migratetype. This may introduce totally unintended value as migratetype. Although I haven't heard of any problem report about that, it is better to protect properly. Second, (get/set)_freepage_migrate isn't used properly. I guess that it would be introduced for per cpu page(pcp) performance, but, it is also used by memory isolation, now. For that case, the information isn't enough to use, so we need to fix it. Third, there is the problem on buddy allocator. It doesn't consider migratetype when merging buddy, so pages from cma or isolate region can be moved to other migratetype freelist. It makes CMA failed over and over. To prevent it, the buddy allocator should consider migratetype if CMA/ISOLATE is enabled. This patchset is aimed at fixing these problems and based on v3.13-rc7. Thanks. Joonsoo Kim (7): mm/page_alloc: synchronize get/set pageblock mm/cma: fix cma free page accounting mm/page_alloc: move set_freepage_migratetype() to better place mm/isolation: remove invalid check condition mm/page_alloc: separate interface to set/get migratetype of freepage mm/page_alloc: store freelist migratetype to the page on buddy properly mm/page_alloc: don't merge MIGRATE_(CMA|ISOLATE) pages on buddy include/linux/mm.h | 35 +--- include/linux/mmzone.h |2 ++ include/linux/page-isolation.h |1 - mm/page_alloc.c| 59 ++-- mm/page_isolation.c|5 +--- 5 files changed, 73 insertions(+), 29 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: imx6q: Add missing esai_ahb clock to current clock tree
On Thu, Jan 09, 2014 at 11:49:41AM +0800, Nicolin Chen wrote:
> On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > > static struct clk *clk[clk_max];
> > > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct
> > > device_node *ccm_node)
> > > clk[ecspi5] = imx_clk_gate2("ecspi5","ecspi_root",
> > > base + 0x6c, 8);
> > > clk[enet] = imx_clk_gate2("enet", "ipg",
> > > base + 0x6c, 10);
> > > clk[esai] = imx_clk_gate2("esai", "esai_podf",
> > > base + 0x6c, 16);
> > > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb",
> > > base + 0x6c, 16);
> >
> > Hmm, having two clocks operating on the same gate bit will get us
> > problem in clock disabling. Clock enabling is fine, since either
> > one who calls clk_enable() first will just set the gate bit. But in
> > case that clk_enable() is called on both clocks, and then when either
> > clock calls clk_disable(), the gate bit will be cleared and thus breaks
> > the other one that might still be in use.
>
> Understood. But how could we handle this situation? The only way I can figure
> out is to make sure the driver open/close them at the same time, it's not a
> perfect way though.
Hmm, we generally leave the gate bit to the clock used to access
register, because usually it's the first one to be on and the last one
to be off.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 1/3] r8152: change the descriptor
The r8152 could support RTL8153. Update the relative descriptor. Signed-off-by: Hayes Wang --- drivers/net/usb/Kconfig | 5 +++-- drivers/net/usb/r8152.c | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index 47b0f73..6b638a0 100644 --- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -92,11 +92,12 @@ config USB_RTL8150 module will be called rtl8150. config USB_RTL8152 - tristate "Realtek RTL8152 Based USB 2.0 Ethernet Adapters" + tristate "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters" select MII help This option adds support for Realtek RTL8152 based USB 2.0 - 10/100 Ethernet adapters. + 10/100 Ethernet adapters and RTL8153 based USB 3.0 10/100/1000 + Ethernet adapters. To compile this driver as a module, choose M here: the module will be called r8152. diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index bf7d549..38f3c14 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -26,7 +26,7 @@ /* Version Information */ #define DRIVER_VERSION "v1.03.0 (2013/12/26)" #define DRIVER_AUTHOR "Realtek linux nic maintainers " -#define DRIVER_DESC "Realtek RTL8152 Based USB 2.0 Ethernet Adapters" +#define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters" #define MODULENAME "r8152" #define R8152_PHY_ID 32 -- 1.8.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 3/3] r8152: add supporting the vendor mode only
Remove the limitation that the ecm and r8152 drivers couldn't coexist.
Besides, add the feature to support the vendor mode only. This let
someone who doesn't want to use ecm driver easy to use the vendor
driver without creating the udev rule.
Signed-off-by: Hayes Wang
---
drivers/net/usb/Kconfig | 9 +
drivers/net/usb/cdc_ether.c | 2 +-
drivers/net/usb/r8152.c | 18 ++
drivers/net/usb/r815x.c | 4 ++--
4 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 6b638a0..d36640e 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -102,6 +102,15 @@ config USB_RTL8152
To compile this driver as a module, choose M here: the
module will be called r8152.
+config USB_RTL8152_VENDOR_MODE_ONLY
+ boolean "Force using the vendor mode"
+ depends on USB_RTL8152
+ default n
+ help
+ This would add the devices in the blacklist of the ECM driver.
+ That is, the ECM mode would be disabled, and only the vendor
+ mode could be used.
+
config USB_USBNET
tristate "Multi-purpose USB Networking Framework"
select MII
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 640406a..5c04f8b 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -653,7 +653,7 @@ static const struct usb_device_id products[] = {
.driver_info = 0,
},
-#if defined(CONFIG_USB_RTL8152) || defined(CONFIG_USB_RTL8152_MODULE)
+#if defined(CONFIG_USB_RTL8152_VENDOR_MODE_ONLY)
/* Samsung USB Ethernet Adapters */
{
USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID, 0xa101, USB_CLASS_COMM,
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index eab078b..e59e99a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -450,6 +450,13 @@ enum rtl8152_flags {
#define MCU_TYPE_PLA 0x0100
#define MCU_TYPE_USB 0x
+#if defined(CONFIG_USB_RTL8152_VENDOR_MODE_ONLY)
+ #define REALTEK_USB_DEVICE(vend, prod) USB_DEVICE(vend, prod)
+#else
+ #define REALTEK_USB_DEVICE(vend, prod) \
+ USB_DEVICE_INTERFACE_CLASS(vend, prod, USB_CLASS_VENDOR_SPEC)
+#endif
+
struct rx_desc {
__le32 opts1;
#define RX_LEN_MASK0x7fff
@@ -2733,13 +2740,16 @@ static int rtl_ops_init(struct r8152 *tp, const struct
usb_device_id *id)
static int rtl8152_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
+ struct usb_host_interface *alt = intf->cur_altsetting;
struct usb_device *udev = interface_to_usbdev(intf);
struct r8152 *tp;
struct net_device *netdev;
int ret;
- if (udev->actconfig->desc.bConfigurationValue != 1) {
+ if (alt->desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC) {
+#if defined(CONFIG_USB_RTL8152_VENDOR_MODE_ONLY)
usb_driver_set_configuration(udev, 1);
+#endif
return -ENODEV;
}
@@ -2823,9 +2833,9 @@ static void rtl8152_disconnect(struct usb_interface *intf)
/* table of devices that work with this driver */
static struct usb_device_id rtl8152_table[] = {
- {USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8152)},
- {USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8153)},
- {USB_DEVICE(VENDOR_ID_SAMSUNG, PRODUCT_ID_SAMSUNG)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8152)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8153)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, PRODUCT_ID_SAMSUNG)},
{}
};
diff --git a/drivers/net/usb/r815x.c b/drivers/net/usb/r815x.c
index 5fd2ca6..9934447 100644
--- a/drivers/net/usb/r815x.c
+++ b/drivers/net/usb/r815x.c
@@ -216,7 +216,7 @@ static const struct usb_device_id products[] = {
{
USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8152, USB_CLASS_COMM,
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
-#if defined(CONFIG_USB_RTL8152) || defined(CONFIG_USB_RTL8152_MODULE)
+#if defined(CONFIG_USB_RTL8152_VENDOR_MODE_ONLY)
.driver_info = 0,
#else
.driver_info = (unsigned long) _info,
@@ -226,7 +226,7 @@ static const struct usb_device_id products[] = {
{
USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8153, USB_CLASS_COMM,
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
-#if defined(CONFIG_USB_RTL8152) || defined(CONFIG_USB_RTL8152_MODULE)
+#if defined(CONFIG_USB_RTL8152_VENDOR_MODE_ONLY)
.driver_info = 0,
#else
.driver_info = (unsigned long) _info,
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 2/3] r8152: fix the warnings and a error from checkpatch.pl
Fix the following warnings and error:
- WARNING: usb_free_urb(NULL) is safe this check is probably not required
- WARNING: kfree(NULL) is safe this check is probably not required
- ERROR: do not use C99 // comments
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 42 +++---
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 38f3c14..eab078b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1100,40 +1100,28 @@ static void free_all_mem(struct r8152 *tp)
int i;
for (i = 0; i < RTL8152_MAX_RX; i++) {
- if (tp->rx_info[i].urb) {
- usb_free_urb(tp->rx_info[i].urb);
- tp->rx_info[i].urb = NULL;
- }
+ usb_free_urb(tp->rx_info[i].urb);
+ tp->rx_info[i].urb = NULL;
- if (tp->rx_info[i].buffer) {
- kfree(tp->rx_info[i].buffer);
- tp->rx_info[i].buffer = NULL;
- tp->rx_info[i].head = NULL;
- }
+ kfree(tp->rx_info[i].buffer);
+ tp->rx_info[i].buffer = NULL;
+ tp->rx_info[i].head = NULL;
}
for (i = 0; i < RTL8152_MAX_TX; i++) {
- if (tp->tx_info[i].urb) {
- usb_free_urb(tp->tx_info[i].urb);
- tp->tx_info[i].urb = NULL;
- }
+ usb_free_urb(tp->tx_info[i].urb);
+ tp->tx_info[i].urb = NULL;
- if (tp->tx_info[i].buffer) {
- kfree(tp->tx_info[i].buffer);
- tp->tx_info[i].buffer = NULL;
- tp->tx_info[i].head = NULL;
- }
+ kfree(tp->tx_info[i].buffer);
+ tp->tx_info[i].buffer = NULL;
+ tp->tx_info[i].head = NULL;
}
- if (tp->intr_urb) {
- usb_free_urb(tp->intr_urb);
- tp->intr_urb = NULL;
- }
+ usb_free_urb(tp->intr_urb);
+ tp->intr_urb = NULL;
- if (tp->intr_buff) {
- kfree(tp->intr_buff);
- tp->intr_buff = NULL;
- }
+ kfree(tp->intr_buff);
+ tp->intr_buff = NULL;
}
static int alloc_all_mem(struct r8152 *tp)
@@ -2048,7 +2036,7 @@ static void r8153_first_init(struct r8152 *tp)
/* TX share fifo free credit full threshold */
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_TXFIFO_CTRL, TXFIFO_THR_NORMAL2);
- // rx aggregation
+ /* rx aggregation */
ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_USB_CTRL);
ocp_data &= ~RX_AGG_DISABLE;
ocp_write_word(tp, MCU_TYPE_USB, USB_USB_CTRL, ocp_data);
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iscsi: fix wrong order of opcode and itt in iscsi_handle_reject prompt
On 01/08/2014 08:21 PM, Vaughan Cao wrote: > This patch makes reject messages show right value for opcode and itt, which > is converse previously. > > Signed-off-by: Vaughan Cao > --- > drivers/scsi/libiscsi.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c > index e399561..27547ff 100644 > --- a/drivers/scsi/libiscsi.c > +++ b/drivers/scsi/libiscsi.c > @@ -1013,13 +1013,13 @@ static int iscsi_handle_reject(struct iscsi_conn > *conn, struct iscsi_hdr *hdr, > iscsi_conn_printk(KERN_ERR, conn, > "pdu (op 0x%x itt 0x%x) rejected " > "due to DataDigest error.\n", > - rejected_pdu.itt, opcode); > + opcode, rejected_pdu.itt); > break; > case ISCSI_REASON_IMM_CMD_REJECT: > iscsi_conn_printk(KERN_ERR, conn, > "pdu (op 0x%x itt 0x%x) rejected. Too many " > "immediate commands.\n", > - rejected_pdu.itt, opcode); > + opcode, rejected_pdu.itt); > /* >* We only send one TMF at a time so if the target could not >* handle it, then it should get fixed (RFC mandates that > @@ -1059,8 +1059,8 @@ static int iscsi_handle_reject(struct iscsi_conn *conn, > struct iscsi_hdr *hdr, > default: > iscsi_conn_printk(KERN_ERR, conn, > "pdu (op 0x%x itt 0x%x) rejected. Reason " > - "code 0x%x\n", rejected_pdu.itt, > - rejected_pdu.opcode, reject->reason); > + "code 0x%x\n", rejected_pdu.opcode, > + rejected_pdu.itt, reject->reason); > break; > } > return rc; > Thanks. Acked-by: Mike Christie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 0/3] r8152: behavior modification
The purpose is to add a choice for determining whether add the limitation between r8152 and ecm drivers or not. Hayes Wang (3): r8152: change the descriptor r8152: fix the warnings and a error from checkpatch.pl r8152: add supporting the vendor mode only drivers/net/usb/Kconfig | 14 -- drivers/net/usb/cdc_ether.c | 2 +- drivers/net/usb/r8152.c | 62 ++--- drivers/net/usb/r815x.c | 4 +-- 4 files changed, 45 insertions(+), 37 deletions(-) -- 1.8.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange problem with vxlan!
Hi! For all others, having problems w/ broken multicast: See the solution here: http://article.gmane.org/gmane.linux.kernel/1625590 Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jan 9
Hi all, This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140108: Dropped tree: sh (complex merge conflicts against very old commits) The powerpc tree still had its build failure. The libata tree gained a conflict against the pci tree. The ipsec-next tree gained a conflict against the net-next tree. The sound-asoc tree gained a conflict against the slave-dma tree. The block tree gained a conflict against the btrfs tree. The gpio tree gained a conflict against the leds tree. Non-merge commits (relative to Linus' tree): 7463 7194 files changed, 361132 insertions(+), 181733 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 210 trees (counting Linus' and 29 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (ceb3b0212dfc Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/nouveau/linux-2.6 into drm-fixes) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (1e01c7eb7c43 ARC: Allow conditional multiple inclusion of uapi/asm/unistd.h) Merging arm-current/fixes (0a5ccc86507f ARM: 7933/1: rename ioremap_cached to ioremap_cache) Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated IRQF_DISABLED) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (f991db1cf1bd Merge remote-tracking branch 'agust/merge' into merge) Merging sparc/master (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging net/master (732256b9335f tipc: correctly unlink packets from deferred packet queue) Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in dccp_probe init) Merging sound-current/for-linus (150116bcfbd9 ALSA: hiface: Fix typo in 352800 rate definition) Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers) Merging wireless/master (2eff7c791a18 Merge tag 'nfc-fixes-3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes) Merging driver-core.current/driver-core-linus (413541dd66d5 Linux 3.13-rc5) Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5) Merging usb.current/usb-linus (413541dd66d5 Linux 3.13-rc5) Merging staging.current/staging-linus (413541dd66d5 Linux 3.13-rc5) Merging char-misc.current/char-misc-linus (319e2e3f63c3 Linux 3.13-rc4) Merging input-current/for-linus (8e2f2325b73f Input: xpad - add new USB IDs for Logitech F310 and F710) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (efb753b8e013 crypto: ixp4xx - Fix kernel compile error) Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary pci_set_drvdata()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (44033109e99c SH: Convert out[bwl] macros to inline functions) Merging devicetre
[PATCH] MODSIGN: Fix including certificate twice when the signing_key.x509
From: Chun-Yi Lee This issue was found in devel-pekey branch on linux-modsign.git tree. The x509_certificate_list includes certificate twice when the signing_key.x509 already exists. We can reproduce this issue by making kernel twice, the build log of second time looks like this: ... CHK kernel/config_data.h CERTS kernel/x509_certificate_list - Including cert /ramdisk/working/joey/linux-modsign/signing_key.x509 - Including cert signing_key.x509 ... Actually the build path was the same with the srctree path when building kernel. It causes the size of bzImage increased by packaging certificates twice. v2: Using '$(shell /bin/pwd)' instead of '$(shell pwd)' for more reliable between different shells Cc: Rusty Russell Cc: Josh Boyer Cc: Randy Dunlap Cc: Herbert Xu Cc: "David S. Miller" Cc: Michal Marek Signed-off-by: Chun-Yi Lee Signed-off-by: David Howells --- kernel/Makefile |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/kernel/Makefile b/kernel/Makefile index bc010ee..582fa7a 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -136,7 +136,10 @@ $(obj)/timeconst.h: $(obj)/hz.bc $(src)/timeconst.bc FORCE # ### ifeq ($(CONFIG_SYSTEM_TRUSTED_KEYRING),y) -X509_CERTIFICATES-y := $(wildcard *.x509) $(wildcard $(srctree)/*.x509) +X509_CERTIFICATES-y := $(wildcard *.x509) +ifneq ($(shell /bin/pwd), $(srctree)) +X509_CERTIFICATES-y += $(wildcard $(srctree)/*.x509) +endif X509_CERTIFICATES-$(CONFIG_MODULE_SIG) += $(objtree)/signing_key.x509 X509_CERTIFICATES-raw := $(sort $(foreach CERT,$(X509_CERTIFICATES-y), \ $(or $(realpath $(CERT)),$(CERT -- 1.6.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ims-pcu: Add commands supported by the new version of the FW
On Wed, Jan 08, 2014 at 09:57:20PM -0800, Andrey Smirnov wrote: > On Mon, Jan 6, 2014 at 11:14 PM, Dmitry Torokhov > wrote: > > > > Andrey, were you able to test the patch? > > Hi Dmitry, > > I tested the patch and with exception of a trivial to fix typo/bug it > worked fine. > > I see that you moved the OFN attributes to a dedicated directory, > which I personally like better, but I am not sure if IMS would not > want to push back on it since they might have started to use the API > already. I'll send a new version to Chris so that he can do some > additional testing and see if they can incorporate that naming change. > I'll e-mail you v3 of the patch as soon as that matter becomes more > clear. Andrey, I am pretty sure that the new sysfs layout with OFN group split makes most sense. Luckily this is brand new functionality so IMS should be able to adjust their userspace to accommodate it. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] qlcnic: Convert vmalloc/memset to kcalloc
vmalloc is a limited resource. Don't use it unnecessarily.
It seems this allocation should work with kcalloc.
Remove unnecessary memset(,0,) of buf as it's completely
overwritten as the previously only unset field in
struct qlcnic_pci_func_cfg is now set to 0.
Use kfree instead of vfree.
Use ETH_ALEN instead of 6.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 2 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 16 ++--
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 35d4876..8d7aa4c 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -1267,7 +1267,7 @@ struct qlcnic_pci_func_cfg {
u16 port_num;
u8 pci_func;
u8 func_state;
- u8 def_mac_addr[6];
+ u8 def_mac_addr[ETH_ALEN];
};
struct qlcnic_npar_func_cfg {
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
index b529667..c9b704d 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
@@ -6,7 +6,6 @@
*/
#include
-#include
#include
#include "qlcnic.h"
@@ -927,38 +926,35 @@ static ssize_t qlcnic_sysfs_read_pci_config(struct file
*file,
u32 pci_func_count = qlcnic_get_pci_func_count(adapter);
struct qlcnic_pci_func_cfg *pci_cfg;
struct qlcnic_pci_info *pci_info;
- size_t pci_info_sz, pci_cfg_sz;
+ size_t pci_cfg_sz;
int i, ret;
pci_cfg_sz = pci_func_count * sizeof(*pci_cfg);
if (size != pci_cfg_sz)
return QL_STATUS_INVALID_PARAM;
- pci_info_sz = pci_func_count * sizeof(*pci_info);
- pci_info = vmalloc(pci_info_sz);
+ pci_info = kcalloc(pci_func_count, sizeof(*pci_info), GFP_KERNEL);
if (!pci_info)
return -ENOMEM;
- memset(pci_info, 0, pci_info_sz);
- memset(buf, 0, pci_cfg_sz);
- pci_cfg = (struct qlcnic_pci_func_cfg *)buf;
-
ret = qlcnic_get_pci_info(adapter, pci_info);
if (ret) {
- vfree(pci_info);
+ kfree(pci_info);
return ret;
}
+ pci_cfg = (struct qlcnic_pci_func_cfg *)buf;
for (i = 0; i < pci_func_count; i++) {
pci_cfg[i].pci_func = pci_info[i].id;
pci_cfg[i].func_type = pci_info[i].type;
+ pci_cfg[i].func_state = 0;
pci_cfg[i].port_num = pci_info[i].default_port;
pci_cfg[i].min_bw = pci_info[i].tx_min_bw;
pci_cfg[i].max_bw = pci_info[i].tx_max_bw;
memcpy(_cfg[i].def_mac_addr, _info[i].mac, ETH_ALEN);
}
- vfree(pci_info);
+ kfree(pci_info);
return size;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arch: use ASM_NL instead of ';' for assembler new line character in the macro
Forwarding to Chen's email address:
On Monday 06 January 2014 02:56 PM, Michal Marek wrote:
> On 2014-01-06 06:36, Vineet Gupta wrote:
>> Hi Michal,
>>
>> On Friday 03 January 2014 06:08 PM, Michal Marek wrote:
>>> On 2013-11-21 10:58, Vineet Gupta wrote:
On 11/01/2013 11:15 AM, Vineet Gupta wrote:
> +CC Sam, Tim, Joe, Michal, David
>
> Guys can you please take a look at this patch and suggest the best way to
> merge.
>
> The root cause is some gas ports (including ARC) use ';' for comment (vs.
> newline)
> More background at https://lkml.org/lkml/2013/10/24/365
Ping ! Any objections to this. Given that this is exception case, it is
simpler
than defining a Kconfig control.
-Vineet
>
> On 10/29/2013 07:21 AM, Chen Gang wrote:
>> For some assemblers, they use another character as newline in a macro
>> (e.g. arc uses '`'), so for generic assembly code, need use ASM_NL (a
>> macro) instead of ';' for it.
>>
>> Also need notice about code styles ('\t' for each line).
>>
>>
>> Signed-off-by: Chen Gang
>
>>
>> Did you hit reply by mistake - as I can't seem to find any comments...
>
> Oops :). I wanted to ask if this is the final patch that should be
> merged, or if there are more known instances of .S code that needs
> s/;/ASM_NL/. I did not find any suspects outside arch/ by grepping. If
> this is the final patch, Chen, could you please resubmit it? I do not
> have the original copy.
>
> Michal
>
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] ata: ahci_platform: Manage SATA PHY
On 01/08/2014 05:16 PM, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 16:58:15 Roger Quadros wrote:
>> hpriv->phy = devm_phy_get(dev, "sata-phy");
>> if (IS_ERR(hpriv->phy)) {
>> if (PTR_ERR(hpriv->phy) == -ENODEV)
>> goto continue;
>>
>> dev_err(dev, "couldn't get sata-phy\n");
>> rc = PTR_ERR(hpriv->phy);
>> goto disable_unprepare_clk;
>> }
>>
>> continue:
>>
>> if (!IS_ERR(hpriv->phy)) {
>> rc = phy_init(hpriv->phy);
>> if (rc)
>> goto disable_unprepare_clk;
>>
>> rc = phy_power_on(hpriv->phy);
>> if (rc) {
>> phy_exit(hpriv->phy);
>> goto disable_unprepare_clk;
>> }
>> }
>
> As I said, I'd prefer to set hpriv->phy to NULL in case of -ENODEV,
> but functionally it seems right (with the fixup from your other mail).
>
Why do you prefer setting hpriv->phy to NULL instead of using IS_ERR() check
before hpriv->phy is used?
The latter seems to be the norm at least among clock framework users.
> One more comment: you shouldn't print an error message before
> returning -EPROBE_DEFER, so if you want to keep that message,
> you have to check for that return value after all.
>
Right.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH CFT] ARM:VERSATILE: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default
This patch enables ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR as default configs to versatile platform. Introduction of PHYS_VIRT config as default enables phy-to-virt and virt-to-phy translation functions at boot and module loading time, and enforce dynamic reallocation of memory. PHYS_VIRT config is mutually exclusive to XIP_KERNEL, XIP_KERNEL is used in systems with NOR flash devices. AUTO_ZRELADDR config enables auto calculation of the decompressed kernel image address. AUTO_ZRELADDR config is mutually exclusive to ZBOOT_ROM, and also assumes zImage to be loaded in the first 128MiB from start of memory. CFT::Call For Testing Requesting maintainers of Versatile platform to evaluate the changes on the board and comment, as I dont have the board for testing and also requesting an ACK. Signed-off-by: panchaxari Cc: Jon Medhurst (Tixy) Cc: Will Deacon Cc: Pawel Moll Cc: Russell King Cc: Linus Walleij Cc: Rob Herring Cc: Arnd Bergmann Cc: Nicolas Pitre Cc: Peter Maydell Cc: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- arch/arm/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 7f316c0..077ef9d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -348,8 +348,10 @@ config ARCH_VERSATILE bool "ARM Ltd. Versatile family" select ARCH_WANT_OPTIONAL_GPIOLIB select ARM_AMBA + select ARM_PATCH_PHYS_VIRT select ARM_TIMER_SP804 select ARM_VIC + select AUTO_ZRELADDR select CLKDEV_LOOKUP select GENERIC_CLOCKEVENTS select HAVE_MACH_CLKDEV -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 0/4] PHY: for 3.14
On Thursday 09 January 2014 09:06 AM, Greg KH wrote: > On Wed, Jan 08, 2014 at 10:54:13AM +0530, Kishon Vijay Abraham I wrote: >> Hi Greg, >> >> On Thursday 26 December 2013 10:17 PM, Kishon Vijay Abraham I wrote: >>> Hi Greg, >>> >>> here's the patches for 3.14. It contains few fixes on phy-core and added a >>> new >>> PHY driver used by SATA in Marvell SoCs. >>> >>> Let me know if you need any changes. >>> >>> Thanks >>> Kishon >>> >>> The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: >>> >>> Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) >>> >>> are available in the git repository at: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git >>> tags/for_3.14 >>> >>> for you to fetch changes up to e3eae85773ebd2165d19ca8661cca3b9c60b2ba1: >>> >>> Phy: Add a PHY driver for Marvell MVEBU SATA PHY. (2013-12-24 23:52:58 >>> +0530) >>> >>> >>> Pull request for PHY subsystem contains few fixes in PHY-CORE mostly >>> w.r.t PM and reference counting and also a new PHY driver used by SATA >>> in Marvell SoC. >>> >>> >>> Andrew Lunn (1): >>> Phy: Add a PHY driver for Marvell MVEBU SATA PHY. >>> >>> Felipe Balbi (1): >>> phy: core: properly handle failure of pm_runtime_get functions >>> >>> Kishon Vijay Abraham I (2): >>> phy: phy-core: increment refcounting variables only on 'success' >>> phy: phy-core.c: remove unnecessary initialization of local variables\ >> >> >> Will you be taking these patches? > > Yes, sorry, catching up from my vacation backlog... no problem, thanks. -Kishon > > greg k-h > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ims-pcu: Add commands supported by the new version of the FW
On Mon, Jan 6, 2014 at 11:14 PM, Dmitry Torokhov wrote: > > Andrey, were you able to test the patch? Hi Dmitry, I tested the patch and with exception of a trivial to fix typo/bug it worked fine. I see that you moved the OFN attributes to a dedicated directory, which I personally like better, but I am not sure if IMS would not want to push back on it since they might have started to use the API already. I'll send a new version to Chris so that he can do some additional testing and see if they can incorporate that naming change. I'll e-mail you v3 of the patch as soon as that matter becomes more clear. Thanks, Andrey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the gpio tree with the leds tree
On 9 January 2014 11:19, Stephen Rothwell wrote:
> Hi Linus,
>
> Today's linux-next merge of the gpio tree got a conflict in
> drivers/leds/leds-s3c24xx.c between commit cfc7937fb6bd ("leds: s3c24xx:
> Remove hardware.h inclusion") from the leds tree and commit 224feb33a645
> ("leds: s3c24xx: Fix build failure") from the gpio tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/leds/leds-s3c24xx.c
> index b7876eb09e8c,87cf215af798..
> --- a/drivers/leds/leds-s3c24xx.c
> +++ b/drivers/leds/leds-s3c24xx.c
> @@@ -18,9 -18,11 +18,10 @@@
> #include
> #include
> #include
> +#include
>
> -#include
> #include
> + #include
> -#include
>
> /* our context */
>
Looks good. Thanks Stephen.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the gpio tree with the leds tree
Hi Linus,
Today's linux-next merge of the gpio tree got a conflict in
drivers/leds/leds-s3c24xx.c between commit cfc7937fb6bd ("leds: s3c24xx:
Remove hardware.h inclusion") from the leds tree and commit 224feb33a645
("leds: s3c24xx: Fix build failure") from the gpio tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/leds/leds-s3c24xx.c
index b7876eb09e8c,87cf215af798..
--- a/drivers/leds/leds-s3c24xx.c
+++ b/drivers/leds/leds-s3c24xx.c
@@@ -18,9 -18,11 +18,10 @@@
#include
#include
#include
+#include
-#include
#include
+ #include
-#include
/* our context */
pgpao8E06VKio.pgp
Description: PGP signature
[PATCH] mm/swap: fix race on swap_info reuse between swapoff and swapon
swapoff clear swap_info's SWP_USED flag prematurely and free its resources after that. A concurrent swapon will reuse this swap_info while its previous resources are not cleared completely. These late freed resources are: - p->percpu_cluster - swap_cgroup_ctrl[type] - block_device setting - inode->i_flags &= ~S_SWAPFILE This patch clear SWP_USED flag after all its resources freed, so that swapon can reuse this swap_info by alloc_swap_info() safely. Signed-off-by: Weijie Yang --- mm/swapfile.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/mm/swapfile.c b/mm/swapfile.c index 612a7c9..89071c3 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1922,7 +1922,6 @@ SYSCALL_DEFINE1(swapoff, const char __user *, specialfile) p->swap_map = NULL; cluster_info = p->cluster_info; p->cluster_info = NULL; - p->flags = 0; frontswap_map = frontswap_map_get(p); spin_unlock(>lock); spin_unlock(_lock); @@ -1948,6 +1947,16 @@ SYSCALL_DEFINE1(swapoff, const char __user *, specialfile) mutex_unlock(>i_mutex); } filp_close(swap_file, NULL); + + /* + * clear SWP_USED flag after all resources freed + * so that swapon can reuse this swap_info in alloc_swap_info() safely + * it is ok to not hold p->lock after we cleared its SWP_WRITEOK + */ + spin_lock(_lock); + p->flags = 0; + spin_unlock(_lock); + err = 0; atomic_inc(_poll_event); wake_up_interruptible(_poll_wait); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] regmap: fix a potential leak in regmap_bulk_write()
Static checkers complain that there is an error path where
_regmap_raw_write() fails and we goto out without freeing the "wval"
buffer.
Signed-off-by: Dan Carpenter
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 062f59860091..939f9b26d5ee 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1514,7 +1514,7 @@ int regmap_bulk_write(struct regmap *map, unsigned int
reg, const void *val,
{
int ret = 0, i;
size_t val_bytes = map->format.val_bytes;
- void *wval;
+ void *wval = NULL;
if (!map->bus)
return -EINVAL;
@@ -1555,10 +1555,10 @@ int regmap_bulk_write(struct regmap *map, unsigned int
reg, const void *val,
ret = _regmap_raw_write(map, reg, wval, val_bytes * val_count);
}
- if (val_bytes != 1)
- kfree(wval);
out:
+ if (val_bytes != 1)
+ kfree(wval);
map->unlock(map->lock_arg);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get
On Tue, Jan 07, 2014 at 07:08:25AM -0800, Eric Dumazet wrote:
> On Tue, 2014-01-07 at 14:31 +0400, Andrey Vagin wrote:
> > Lets look at destroy_conntrack:
> >
> > hlist_nulls_del_rcu(>tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
> > ...
> > nf_conntrack_free(ct)
> > kmem_cache_free(net->ct.nf_conntrack_cachep, ct);
> >
> > net->ct.nf_conntrack_cachep is created with SLAB_DESTROY_BY_RCU.
> >
> > The hash is protected by rcu, so readers look up conntracks without
> > locks.
> > A conntrack is removed from the hash, but in this moment a few readers
> > still can use the conntrack. Then this conntrack is released and another
> > thread creates conntrack with the same address and the equal tuple.
> > After this a reader starts to validate the conntrack:
> > * It's not dying, because a new conntrack was created
> > * nf_ct_tuple_equal() returns true.
> >
> > But this conntrack is not initialized yet, so it can not be used by two
> > threads concurrently. In this case BUG_ON may be triggered from
> > nf_nat_setup_info().
> >
> > Florian Westphal suggested to check the confirm bit too. I think it's
> > right.
> >
> > task 1 task 2 task 3
> > nf_conntrack_find_get
> > nf_conntrack_find
> > destroy_conntrack
> > hlist_nulls_del_rcu
> > nf_conntrack_free
> > kmem_cache_free
> > __nf_conntrack_alloc
> > kmem_cache_alloc
> >
> > memset(>tuplehash[IP_CT_DIR_MAX],
> > if (nf_ct_is_dying(ct))
> > if (!nf_ct_tuple_equal()
> >
> > I'm not sure, that I have ever seen this race condition in a real life.
> > Currently we are investigating a bug, which is reproduced on a few node.
> > In our case one conntrack is initialized from a few tasks concurrently,
> > we don't have any other explanation for this.
>
> >
> > Cc: Florian Westphal
> > Cc: Pablo Neira Ayuso
> > Cc: Patrick McHardy
> > Cc: Jozsef Kadlecsik
> > Cc: "David S. Miller"
> > Cc: Cyrill Gorcunov
> > Signed-off-by: Andrey Vagin
> > ---
> > net/netfilter/nf_conntrack_core.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/netfilter/nf_conntrack_core.c
> > b/net/netfilter/nf_conntrack_core.c
> > index 43549eb..7a34bb2 100644
> > --- a/net/netfilter/nf_conntrack_core.c
> > +++ b/net/netfilter/nf_conntrack_core.c
> > @@ -387,8 +387,12 @@ begin:
> > !atomic_inc_not_zero(>ct_general.use)))
> > h = NULL;
> > else {
> > + /* A conntrack can be recreated with the equal tuple,
> > +* so we need to check that the conntrack is initialized
> > +*/
> > if (unlikely(!nf_ct_tuple_equal(tuple, >tuple) ||
> > -nf_ct_zone(ct) != zone)) {
> > +nf_ct_zone(ct) != zone) ||
> > +!nf_ct_is_confirmed(ct)) {
> > nf_ct_put(ct);
> > goto begin;
> > }
>
> I do not think this is the right way to fix this problem (if said
> problem is confirmed)
>
> Remember the rule about SLAB_DESTROY_BY_RCU :
>
> When a struct is freed, then reused, its important to set the its refcnt
> (from 0 to 1) only when the structure is fully ready for use.
>
> If a lookup finds a structure which is not yet setup, the
> atomic_inc_not_zero() will fail.
>
> Take a look at sk_clone_lock() and Documentation/RCU/rculist_nulls.txt
>
I have one more question. Looks like I found another problem.
init_conntrack:
hlist_nulls_add_head_rcu(>tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
>ct.unconfirmed);
__nf_conntrack_hash_insert:
hlist_nulls_add_head_rcu(>tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
>ct.hash[hash]);
We use one hlist_nulls_node to add a conntrack into two different lists.
As far as I understand, it's unacceptable in case of
SLAB_DESTROY_BY_RCU.
Lets imagine that we have two threads. The first one enumerates objects
from a first list, the second one recreates an object and insert it in a
second list. If a first thread in this moment stays on the object, it
can read "next", when it's in the second list, so it will continue
to enumerate objects from the second list. It is not what we want, isn't
it?
cpu1cpu2
hlist_nulls_for_each_entry_rcu(ct)
destroy_conntrack
kmem_cache_free
init_conntrack
hlist_nulls_add_head_rcu
ct = ct->next
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [PATCH v5 3/9] phy: Add new Exynos USB 2.0 PHY driver
Hi,
On Wednesday 08 January 2014 11:26 PM, Kamil Debski wrote:
> Hi,
>
>> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
>> Sent: Monday, January 06, 2014 11:12 AM
>>
>> Hi,
>>
>> On Friday 20 December 2013 06:54 PM, Kamil Debski wrote:
>>> Add a new driver for the Exynos USB 2.0 PHY. The new driver uses the
>>> generic PHY framework. The driver includes support for the Exynos
>> 4x10
>>> and 4x12 SoC families.
>>>
>>> Signed-off-by: Kamil Debski
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> .../devicetree/bindings/phy/samsung-phy.txt| 55
>>> drivers/phy/Kconfig| 29 ++
>>> drivers/phy/Makefile |3 +
>>> drivers/phy/phy-exynos4210-usb2.c | 257
>>
>>> drivers/phy/phy-exynos4212-usb2.c | 306
>>
>>> drivers/phy/phy-samsung-usb2.c | 226
>> +++
>>> drivers/phy/phy-samsung-usb2.h | 67 +
>>> 7 files changed, 943 insertions(+)
>>> create mode 100644 drivers/phy/phy-exynos4210-usb2.c
>>> create mode 100644 drivers/phy/phy-exynos4212-usb2.c
>>> create mode 100644 drivers/phy/phy-samsung-usb2.c
>>> create mode 100644 drivers/phy/phy-samsung-usb2.h
>>>
>> .
>> .
>>
>> .
>> .
>>
>>> diff --git a/drivers/phy/phy-samsung-usb2.h
>>> b/drivers/phy/phy-samsung-usb2.h new file mode 100644 index
>>> 000..ab89f91
>>> --- /dev/null
>>> +++ b/drivers/phy/phy-samsung-usb2.h
>>> @@ -0,0 +1,67 @@
>>> +/*
>>> + * Samsung SoC USB 1.1/2.0 PHY driver
>>> + *
>>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
>>> + * Author: Kamil Debski
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> +modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +
>>> +#ifndef _PHY_EXYNOS_USB2_H
>>> +#define _PHY_EXYNOS_USB2_H
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define KHZ 1000
>>> +#define MHZ (KHZ * KHZ)
>>> +
>>> +struct samsung_usb2_phy_driver;
>>> +struct samsung_usb2_phy_instance;
>>> +struct samsung_usb2_phy_config;
>>> +
>>> +struct samsung_usb2_phy_instance {
>>> + const struct samsung_usb2_common_phy *cfg;
>>> + struct clk *clk;
>>> + struct phy *phy;
>>> + struct samsung_usb2_phy_driver *drv;
>>> + unsigned long rate;
>>> + u32 clk_reg_val;
>>> + bool enabled;
>>> +};
>>> +
>>> +struct samsung_usb2_phy_driver {
>>> + const struct samsung_usb2_phy_config *cfg;
>>> + struct clk *clk;
>>> + struct device *dev;
>>> + void __iomem *reg_phy;
>>> + struct regmap *reg_pmu;
>>> + struct regmap *reg_sys;
>>> + spinlock_t lock;
>>> + struct samsung_usb2_phy_instance instances[0];
>>
>> I think having instances as array here would allocate more space while
>> allocating 'samsung_usb2_phy_driver' in 'samsung_usb2_phy_probe'.
>>
>
> I am not sure if I understand you correctly here. Maybe I will explain
> what I intended to write. An array with size 0 at the end of a structure
> takes no space in the structure. The benefit of using it is that after
> the structure one can allocate a number of the array elements and
> address them easily. Another option would be placing pointer in the
> samsung_usb2_phy_instance and allocate memory separately, but this would
> involve two allocations and a pointer would be always present in the
> structure.
Al-right.. makes sense.
Thanks
Kishon
>
> Best wishes,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.13-rc2 phy-twl4030-usb.c - Timeout setting T2 HSUSB PHY DPLL
Hi Marek, I have no idea what is happening there. Have you tried using device tree boot? Board file boot support would be dropped eventually. Did you try if I2C read write to the twl4030 device works and all necessary clocks/supplies are present? Kishon, do you know what is causing the USB DPLL failure there? cheers, -roger On 01/09/2014 02:31 AM, Belisko Marek wrote: > Any pointers? Still present in 3.13-rc7. > > On Wed, Dec 4, 2013 at 1:22 PM, Roger Quadros wrote: >> +Kishon >> >> On 12/03/2013 11:33 PM, Belisko Marek wrote: >>> Hi, >>> >>> current 3.13-rcX break usb support on gta04 board (similar to >>> beagleboard) when booting via board file. >>> >>> In console we can see messages: >>> [ 5227.287841] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL >>> clock >>> [ 5232.936096] omap_musb_mailbox: musb core is not yet ready >>> [ 5233.958160] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL >>> clock >>> [ 5235.058227] twl4030_usb twl4030_usb: Timeout setting T2 HSUSB PHY DPLL >>> clock >>> >>> Any pointer what could cause that? (in 3.12 usb works fine) >>> >>> BR, >>> >>> marek >>> >> > > BR, > > marek > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] spi: atmel: Refactor spi-atmel to use SPI framework queue
Replace the deprecated master->transfer with transfer_one_message()
and allow the SPI subsystem handle all the queuing of messages.
Signed-off-by: Wenyou Yang
Tested-by: Richard Genoud
---
Hi Mark,
Thanks for your feedback.
According to your advice, I prepared this version 2.
The patch is based on the for-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
I tested it on sama5d3xek and at91sam9m10g45ek board.
Richard helped tested it on at91sam9g35-ek board.
Best Regards,
Wenyou Yang
v2 changelog:
1./ Rebase the latest for-next branch included the patch from Richard.
2./ remove the lock on complete(>xfer_completion).
3./ rework the xfer->cs_change is true.
4./ remove the member stopping of struct atmel_spi.
drivers/spi/spi-atmel.c | 678 +++
1 file changed, 220 insertions(+), 458 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index b96f9a8..b0842f7 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -189,6 +189,8 @@
*/
#define DMA_MIN_BYTES 16
+#define SPI_DMA_TIMEOUT(msecs_to_jiffies(1000))
+
struct atmel_spi_dma {
struct dma_chan *chan_rx;
struct dma_chan *chan_tx;
@@ -220,17 +222,13 @@ struct atmel_spi {
int irq;
struct clk *clk;
struct platform_device *pdev;
- struct spi_device *stay;
- u8 stopping;
- struct list_headqueue;
- struct tasklet_struct tasklet;
struct spi_transfer *current_transfer;
unsigned long current_remaining_bytes;
- struct spi_transfer *next_transfer;
- unsigned long next_remaining_bytes;
int done_status;
+ struct completion xfer_completion;
+
/* scratch buffer */
void*buffer;
dma_addr_t buffer_dma;
@@ -241,6 +239,9 @@ struct atmel_spi {
booluse_pdc;
/* dmaengine data */
struct atmel_spi_dmadma;
+
+ boolkeep_cs;
+ boolcs_active;
};
/* Controller-specific per-slave state */
@@ -376,17 +377,6 @@ static inline bool atmel_spi_use_dma(struct atmel_spi *as,
return as->use_dma && xfer->len >= DMA_MIN_BYTES;
}
-static inline int atmel_spi_xfer_is_last(struct spi_message *msg,
- struct spi_transfer *xfer)
-{
- return msg->transfers.prev == >transfer_list;
-}
-
-static inline int atmel_spi_xfer_can_be_chained(struct spi_transfer *xfer)
-{
- return xfer->delay_usecs == 0 && !xfer->cs_change;
-}
-
static int atmel_spi_dma_slave_config(struct atmel_spi *as,
struct dma_slave_config *slave_config,
u8 bits_per_word)
@@ -513,23 +503,20 @@ static void dma_callback(void *data)
struct spi_master *master = data;
struct atmel_spi*as = spi_master_get_devdata(master);
- /* trigger SPI tasklet */
- tasklet_schedule(>tasklet);
+ complete(>xfer_completion);
}
/*
* Next transfer using PIO.
- * lock is held, spi tasklet is blocked
*/
static void atmel_spi_next_xfer_pio(struct spi_master *master,
struct spi_transfer *xfer)
{
struct atmel_spi*as = spi_master_get_devdata(master);
+ unsigned long xfer_pos = xfer->len - as->current_remaining_bytes;
dev_vdbg(master->dev.parent, "atmel_spi_next_xfer_pio\n");
- as->current_remaining_bytes = xfer->len;
-
/* Make sure data is not remaining in RDR */
spi_readl(as, RDR);
while (spi_readl(as, SR) & SPI_BIT(RDRF)) {
@@ -537,13 +524,14 @@ static void atmel_spi_next_xfer_pio(struct spi_master
*master,
cpu_relax();
}
- if (xfer->tx_buf)
+ if (xfer->tx_buf) {
if (xfer->bits_per_word > 8)
- spi_writel(as, TDR, *(u16 *)(xfer->tx_buf));
+ spi_writel(as, TDR, *(u16 *)(xfer->tx_buf + xfer_pos));
else
- spi_writel(as, TDR, *(u8 *)(xfer->tx_buf));
- else
+ spi_writel(as, TDR, *(u8 *)(xfer->tx_buf + xfer_pos));
+ } else {
spi_writel(as, TDR, 0);
+ }
dev_dbg(master->dev.parent,
" start pio xfer %p: len %u tx %p rx %p bitpw %d\n",
@@ -556,7 +544,6 @@ static void atmel_spi_next_xfer_pio(struct spi_master
*master,
/*
* Submit next transfer for DMA.
- * lock is held, spi tasklet is blocked
*/
static int atmel_spi_next_xfer_dma_submit(struct spi_master *master,
struct spi_transfer *xfer,
@@ -747,71 +734,37 @@ static int atmel_spi_set_xfer_speed(struct atmel_spi *as,
* lock is
Re: [PATCH 2/3] regulator: Add support for S2MPA01 regulator
Hi Mark,
Thanks for reviewing.
On 8 January 2014 18:00, Mark Brown wrote:
> On Wed, Jan 08, 2014 at 11:56:29AM +0530, Sachin Kamat wrote:
>
>> + if (!iodev->dev->of_node) {
>> + if (pdata) {
>> + goto common_reg;
>> + } else {
>> + dev_err(pdev->dev.parent,
>> + "Platform data or DT node not supplied\n");
>> + return -ENODEV;
>> + }
>> + }
>
> The driver shouldn't need these to probe, it should be able to start in
> read only mode with no configuration.
OK.
>
>> +static int __init s2mpa01_pmic_init(void)
>> +{
>> + return platform_driver_register(_pmic_driver);
>> +}
>> +subsys_initcall(s2mpa01_pmic_init);
>
> module_platform_driver().
Just a small doubt here. Wouldn't changing this from subsys init to module init
cause problems to devices like mmc which would want the regulators available
(where they are not already enabled by the boot loader)?
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Arndale Timer Interrupt Question
I am a bit confused on the interrupt number for CNTVIRQ..CNTHPIRQ. Can you please help here. As per the exynos5 public manual What is the difference between  CPU_nCNTHPIRQ[0] and CNTHPIRQ. While the later has an interrupt ID 26, the former is part of a group with combined interrupt id as 33 for core 0 and 54 for core 1. For a timer interrupt which goes to PL2, which id should be used 26 or 33 for core 0 ? Please clear this confusion. Many Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6 v2] crypto:s5p-sss: validate iv before memcpy
This patch adds code to validate "iv" buffer before trying to memcpy the contents Signed-off-by: Naveen Krishna Chatradhi --- Changes since v1: None drivers/crypto/s5p-sss.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index 7c31a5f..220f123 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -398,8 +398,9 @@ static void s5p_set_aes(struct s5p_aes_dev *dev, struct samsung_aes_varient *var = dev->varient; void __iomem *keystart; - memcpy(dev->ioaddr + SSS_REG_AES_IV_DATA - (var->aes_offset, 0), iv, 0x10); + if (iv) + memcpy(dev->ioaddr + SSS_REG_AES_IV_DATA + (var->aes_offset, 0), iv, 0x10); if (keylen == AES_KEYSIZE_256) keystart = dev->ioaddr + -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6 v2] ARM: dts: exynos5420: add dt node for sss module
This patch adds the device tree node for SSS module
found on Exynos5420
Signed-off-by: Naveen Krishna Chatradhi
TO:
CC: Kukjin Kim
CC:
---
Changes since v1:
Modified dt node name from sss to sss@1083
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 11dd202..0b27902 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -652,4 +652,14 @@
clocks = < 319>, < 318>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
};
+
+ sss@1083 {
+ compatible = "samsung,exynos-secss";
+ reg = <0x1083 0x1>;
+ interrupts = <0 112 0>;
+ clocks = < 471>;
+ clock-names = "secss";
+ samsung,power-domain = <_pd>;
+ };
+
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6 v2] crypto:s5p-sss: Add device tree support
This patch adds device tree support to the s5p-sss.c crypto driver.
Implements a varient struct to address the changes in SSS hardware
on various SoCs from Samsung.
Also, Documentation under devicetree/bindings added.
Signed-off-by: Naveen Krishna Ch
CC: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
Changes since v1:
1. Added description of the SSS module in Documentation
2. Corrected the interrupts description
3. Added varient struct instead of the version variable
.../devicetree/bindings/crypto/samsung-sss.txt | 20 +
drivers/crypto/s5p-sss.c | 81 ++--
2 files changed, 95 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..0e45b0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,20 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ SSS versions:
+ - "samsung,s5p-secss" for S5PV210 SoC.
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the SSS module.
+ Two interrupts "feed control and hash" in case of S5PV210
+- clocks : the required gating clock for the SSS module.
+- clock-names : the gating clock name to be requested in the SSS driver.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 93cddeb..78e0c37 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -145,6 +146,20 @@
#define AES_KEY_LEN 16
#define CRYPTO_QUEUE_LEN1
+/**
+ * struct samsung_aes_varient - platform specific SSS driver data
+ * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
+ * @aes_offset: AES register offset from SSS module's base.
+ *
+ * Specifies platform specific configuration of SSS module.
+ * Note: A structure for driver specific platform data is used for future
+ * expansion of its usage.
+ */
+struct samsung_aes_varient {
+ boolhas_hash_irq;
+ unsigned intaes_offset;
+};
+
struct s5p_aes_reqctx {
unsigned long mode;
};
@@ -173,10 +188,56 @@ struct s5p_aes_dev {
struct crypto_queue queue;
boolbusy;
spinlock_t lock;
+
+ struct samsung_aes_varient *varient;
};
static struct s5p_aes_dev *s5p_dev;
+static struct samsung_aes_varient s5p_aes_data = {
+ .has_hash_irq = true,
+ .aes_offset = 0x4000,
+};
+
+static const struct platform_device_id s5p_sss_ids[] = {
+ {
+ .name = "s5p-secss",
+ .driver_data= (kernel_ulong_t)_aes_data,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, s5p_sss_ids);
+
+#ifdef CONFIG_OF
+static const struct of_device_id s5p_sss_dt_match[] = {
+ {
+ .compatible = "samsung,s5p-secss",
+ .data = (void *)_aes_data,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+#else
+static struct of_device_id s5p_sss_dt_match[] = {
+ { },
+};
+#endif
+
+static inline struct samsung_aes_varient *find_s5p_sss_version
+ (struct platform_device *pdev)
+{
+ if (IS_ENABLED(CONFIG_OF)) {
+ if (pdev->dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(s5p_sss_dt_match,
+ pdev->dev.of_node);
+ return (struct samsung_aes_varient *)match->data;
+ }
+ }
+ return (struct samsung_aes_varient *)
+ platform_get_device_id(pdev)->driver_data;
+}
+
static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist *sg)
{
SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
@@ -564,6 +625,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
struct s5p_aes_dev *pdata;
struct device *dev = >dev;
struct resource*res;
+ struct samsung_aes_varient *varient;
if (s5p_dev)
return -EEXIST;
@@ -580,6 +642,8 @@ static int s5p_aes_probe(struct platform_device *pdev)
resource_size(res), pdev->name))
return -EBUSY;
+ varient = find_s5p_sss_version(pdev);
+
[PATCH 3/6 v2] crypto:s5p-sss: Add support for SSS module on Exynos
This patch adds new compatible and varient to support the SSS module
on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250) for which
1. AES register are at an offset of 0x200 and
2. hash interrupt is not available
Signed-off-by: Naveen Krishna Ch
CC: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
Changes since v1:
1. Used varient struct
2. Added description in Documentation
.../devicetree/bindings/crypto/samsung-sss.txt | 20 +
drivers/crypto/s5p-sss.c | 43 ++--
2 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
index 0e45b0d..4531da2 100644
--- a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -8,13 +8,33 @@ The SSS module in S5PV210 SoC supports the following:
-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
-- PRNG: Pseudo Random Number Generator
+The SSS module in Exynos4 (Exynos4210) and
+Exynos5 (Exynos5420 and Exynos5250) SoCs
+supports the following also:
+-- ARCFOUR (ARC4)
+-- True Random Number Generator (TRNG)
+-- Secure Key Manager
+
Required properties:
- compatible : Should contain entries for this and backward compatible
SSS versions:
- "samsung,s5p-secss" for S5PV210 SoC.
+ - "samsung,exynos-secss" for Exynos4210, Exynos5250 and Exynos5420 SoCs.
- reg : Offset and length of the register set for the module
- interrupts : the interrupt-specifier for the SSS module.
Two interrupts "feed control and hash" in case of S5PV210
+ One interrupts "feed control" in case of Exynos4210,
+ Exynos5250 and Exynos5420 SoCs.
- clocks : the required gating clock for the SSS module.
- clock-names : the gating clock name to be requested in the SSS driver.
+
+Example:
+ /* SSS_VER_5 */
+ sss@1083 {
+ compatible = "samsung,exynos-secss";
+ reg = <0x1083 0x1>;
+ interrupts = <0 112 0>;
+ clocks = < 471>;
+ clock-names = "secss";
+ };
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 78e0c37..7c31a5f 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -106,7 +106,7 @@
#define SSS_REG_FCPKDMAO0x005C
/* AES registers */
-#define SSS_REG_AES_CONTROL 0x4000
+#define SSS_REG_AES_CONTROL0x00
#define SSS_AES_BYTESWAP_DI _BIT(11)
#define SSS_AES_BYTESWAP_DO _BIT(10)
#define SSS_AES_BYTESWAP_IV _BIT(9)
@@ -122,21 +122,26 @@
#define SSS_AES_CHAIN_MODE_CTR _SBF(1, 0x02)
#define SSS_AES_MODE_DECRYPT_BIT(0)
-#define SSS_REG_AES_STATUS 0x4004
+#define SSS_REG_AES_STATUS 0x04
#define SSS_AES_BUSY_BIT(2)
#define SSS_AES_INPUT_READY _BIT(1)
#define SSS_AES_OUTPUT_READY_BIT(0)
-#define SSS_REG_AES_IN_DATA(s) (0x4010 + (s << 2))
-#define SSS_REG_AES_OUT_DATA(s) (0x4020 + (s << 2))
-#define SSS_REG_AES_IV_DATA(s) (0x4030 + (s << 2))
-#define SSS_REG_AES_CNT_DATA(s) (0x4040 + (s << 2))
-#define SSS_REG_AES_KEY_DATA(s) (0x4080 + (s << 2))
+#define SSS_REG_AES_IN_DATA(off, s)((off + 0x10) + (s << 2))
+#define SSS_REG_AES_OUT_DATA(off, s) ((off + 0x20) + (s << 2))
+#define SSS_REG_AES_IV_DATA(off, s)((off + 0x30) + (s << 2))
+#define SSS_REG_AES_CNT_DATA(off, s) ((off + 0x40) + (s << 2))
+#define SSS_REG_AES_KEY_DATA(off, s) ((off + 0x80) + (s << 2))
#define SSS_REG(dev, reg) ((dev)->ioaddr + (SSS_REG_##reg))
#define SSS_READ(dev, reg) __raw_readl(SSS_REG(dev, reg))
#define SSS_WRITE(dev, reg, val)__raw_writel((val), SSS_REG(dev, reg))
+#define SSS_AES_REG(dev, reg) ((dev)->ioaddr + SSS_REG_##reg + \
+ dev->varient->aes_offset)
+#define SSS_AES_WRITE(dev, reg, val)__raw_writel((val), \
+ SSS_AES_REG(dev, reg))
+
/* HW engine modes */
#define FLAGS_AES_DECRYPT _BIT(0)
#define FLAGS_AES_MODE_MASK _SBF(1, 0x03)
@@ -199,6 +204,11 @@ static struct samsung_aes_varient s5p_aes_data = {
.aes_offset = 0x4000,
};
+static struct samsung_aes_varient exynos_aes_data = {
+ .has_hash_irq = false,
+ .aes_offset = 0x200,
+};
+
static const struct platform_device_id s5p_sss_ids[] = {
{
.name = "s5p-secss",
@@ -214,6 +224,10 @@ static const struct of_device_id s5p_sss_dt_match[] = {
.compatible = "samsung,s5p-secss",
.data = (void *)_aes_data,
},
+ {
+ .compatible = "samsung,exynos-secss",
+ .data = (void
[PATCH 4/6 v2] crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver
From: Naveen Krishna Ch This patch modifies Kconfig such that ARCH_EXYNOS SoCs which includes (Exynos4210, Exynos5250 and Exynos5420) can also select Samsung SSS(Security SubSystem) driver. Signed-off-by: Naveen Krishna Ch CC: Herbert Xu CC: David S. Miller CC: Vladimir Zapolskiy TO: CC: --- Changes since v1: SSS module on Exynos4210 and Exynos5250, Exynso5420 are alike hence, modifying the Kconfig to select the s5p-sss.c driver for all SoCs supporting ARCH_EXYNOS drivers/crypto/Kconfig |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index f4fd837..193e8b1 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -300,15 +300,15 @@ config CRYPTO_DEV_DCP capabilities of the DCP co-processor config CRYPTO_DEV_S5P - tristate "Support for Samsung S5PV210 crypto accelerator" - depends on ARCH_S5PV210 + tristate "Support for Samsung crypto accelerator" + depends on ARCH_S5PV210 || ARCH_EXYNOS select CRYPTO_AES select CRYPTO_ALGAPI select CRYPTO_BLKCIPHER help This option allows you to have support for S5P crypto acceleration. - Select this to offload Samsung S5PV210 or S5PC110 from AES - algorithms execution. + Select this to offload Samsung S5PV210 or S5PC110, Exynos4210, + Exynos5250 and Exynos5420 from AES algorithms execution. config CRYPTO_DEV_TEGRA_AES tristate "Support for TEGRA AES hw engine" -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6 v2] crypto:s5p-sss: Use platform_get_irq() instead of _byname()
From: Naveen Krishna Ch
This patch uses the platform_get_irq() instead of the
platform_get_irq_byname(). Making feeder control interrupt
as resource "0" and hash interrupt as "1".
reasons for this change.
1. Cannot find any Arch which is currently using this driver
2. Samsung Exynos4 and 5 SoCs only use the feeder control interrupt
3. Patches adding support for DT and H/W version are in pipeline
Signed-off-by: Naveen Krishna Ch
CC: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
Changes since v1:
A typo fixed, from err "pdata->irq_hash;" to "pdata->irq_fc;"
drivers/crypto/s5p-sss.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index cf149b1..93cddeb 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -592,29 +592,29 @@ static int s5p_aes_probe(struct platform_device *pdev)
pdata->ioaddr = devm_ioremap(dev, res->start,
resource_size(res));
- pdata->irq_hash = platform_get_irq_byname(pdev, "hash");
- if (pdata->irq_hash < 0) {
- err = pdata->irq_hash;
- dev_warn(dev, "hash interrupt is not available.\n");
+ pdata->irq_fc = platform_get_irq(pdev, 0);
+ if (pdata->irq_fc < 0) {
+ err = pdata->irq_fc;
+ dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
}
- err = devm_request_irq(dev, pdata->irq_hash, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
IRQF_SHARED, pdev->name, pdev);
if (err < 0) {
- dev_warn(dev, "hash interrupt is not available.\n");
+ dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
}
- pdata->irq_fc = platform_get_irq_byname(pdev, "feed control");
- if (pdata->irq_fc < 0) {
- err = pdata->irq_fc;
- dev_warn(dev, "feed control interrupt is not available.\n");
+ pdata->irq_hash = platform_get_irq(pdev, 1);
+ if (pdata->irq_hash < 0) {
+ err = pdata->irq_hash;
+ dev_warn(dev, "hash interrupt is not available.\n");
goto err_irq;
}
- err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata->irq_hash, s5p_aes_interrupt,
IRQF_SHARED, pdev->name, pdev);
if (err < 0) {
- dev_warn(dev, "feed control interrupt is not available.\n");
+ dev_warn(dev, "hash interrupt is not available.\n");
goto err_irq;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Documentation: mfd: Add binding document for S2MPA01
On 8 January 2014 15:11, Mark Rutland wrote:
> On Wed, Jan 08, 2014 at 06:26:30AM +, Sachin Kamat wrote:
>> Added initial binding documentation for S2MPA01 MFD.
>>
>> Signed-off-by: Sachin Kamat
>> ---
>> Documentation/devicetree/bindings/mfd/s2mpa01.txt | 91
>> +
>> 1 file changed, 91 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/s2mpa01.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt
>> b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
>> new file mode 100644
>> index ..ae750a28821b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
>> @@ -0,0 +1,91 @@
>> +
>> +* Samsung S2MPA01 Voltage and Current Regulator
>> +
>> +The Samsung S2MPA01 is a multi-function device which includes high
>> +efficiency buck converters including Dual-Phase buck converter, various
>> LDOs,
>> +and an RTC. It is interfaced to the host controller using an I2C interface.
>> +Each sub-block is addressed by the host system using different I2C slave
>> +addresses.
>> +
>> +Required properties:
>> +- compatible: Should be "samsung,s2mpa01-pmic".
>> +- reg: Specifies the I2C slave address of the PMIC block. It should be 0x66.
>> +
>> +Optional properties:
>> +- interrupt-parent: Specifies the phandle of the interrupt controller to
>> which
>> + the interrupts from s2mpa01 are delivered to.
>> +- interrupts: Interrupt specifiers for interrupt sources.
>
> That sounds a bit odd. How many interrupts might there be? What do they
> signal?
Actually there is only one interrupt line for sending interrupts to
the AP for conditons like sudden
voltage drop, etc. I will make the above sentence singular.
>> +
>> +Optional nodes:
>> +- regulators: The regulators of s2mpa01 that have to be instantiated should
>> be
>> +included in a sub-node named 'regulators'. Regulator nodes included in this
>> +sub-node should be of the format as listed below.
>> +
>> + regulator_name {
>> + [standard regulator constraints];
>> + };
>> +
>
> Why not just say that the regulators node contains regulators in the
> usual format, with reference to the regulator binding?
OK. I will update this (as also suggested by your later comment).
>
>> + regulator-ramp-delay for BUCKs = [6250/12500(default)/25000/5] uV/us
>> +
>> + BUCK[1/2/3/4] supports disabling ramp delay on hardware, so explictly
>> + regulator-ramp-delay = <0> can be used for them to disable ramp delay.
>> + In the absence of the regulator-ramp-delay property, the default ramp
>> + delay will be used.
>> +
>> +NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be
>> set
>> +for a particular group of BUCKs. So provide same
>> regulator-ramp-delay.
>> +Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6],
>> +BUCK[2, 4], and BUCK[8, 9, 10]
>
> It would probably be better to have a heading like "Properties for BUCK
> regulator nodes" for all of the above.
OK.
>
>> +
>> +The regulator constraints inside the regulator nodes use the standard
>> regulator
>> +bindings which are documented elsewhere.
>
> As mentioned above, state this at the beginning and point to the
> regulator bindings.
OK.
>> +
>> +The following are the names of the regulators that the s2mpa01 PMIC block
>> +supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
>> +as per the datasheet of s2mpa01.
>
> So these are what the nodes should be called? (rather than values for
> regulator-name).
Yes. That is the convention followed here.
>
> Otherwise this looks ok to me.
>
Thanks for reviewing.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH CFT] ARM:REALVIEW: Enable AUTO_ZRELADDR by default
This patch enables AUTO_ZRELADDR as default config to Realview platform. AUTO_ZRELADDR config enables auto calculation of the decompressed kernel image address. AUTO_ZRELADDR config is mutually exclusive to ZBOOT_ROM, and also assumes zImage to be loaded in the first 128MiB from start of memory. CFT::Call For Testing Requesting maintainers of Realview platforms to evaluate the changes on the board and comment, as I dont have the board for testing, and also requesting an ACK. Signed-off-by: panchaxari Cc: Will Deacon Cc: Pawel Moll Cc: Russell King Cc: Rob Herring Cc: Viresh Kumar Cc: Shawn Guo Cc: Olof Johansson Cc: Linus Walleij Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- Below lkml link is a quoting by Russell, which explains more on concept of PHYS_VIRT and ZRELADDR - https://lkml.org/lkml/2011/10/14/434 - --- arch/arm/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3dfc3b8..077ef9d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -332,6 +332,7 @@ config ARCH_REALVIEW select ARCH_WANT_OPTIONAL_GPIOLIB select ARM_AMBA select ARM_TIMER_SP804 + select AUTO_ZRELADDR select COMMON_CLK select COMMON_CLK_VERSATILE select GENERIC_CLOCKEVENTS -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/11] pagewalk: update page table walker core
On Wed, Jan 08, 2014 at 03:48:29PM -0800, Andrew Morton wrote:
> On Wed, 11 Dec 2013 17:08:57 -0500 Naoya Horiguchi
> wrote:
>
> > This patch updates mm/pagewalk.c to make code less complex and more
> > maintenable.
> > The basic idea is unchanged and there's no userspace visible effect.
> >
> > Most of existing callback functions need access to vma to handle each entry.
> > So we had better add a new member vma in struct mm_walk instead of using
> > mm_walk->private, which makes code simpler.
> >
> > One problem in current page table walker is that we check vma in pgd loop.
> > Historically this was introduced to support hugetlbfs in the strange manner.
> > It's better and cleaner to do the vma check outside pgd loop.
> >
> > Another problem is that many users of page table walker now use only
> > pmd_entry(), although it does both pmd-walk and pte-walk. This makes code
> > duplication and fluctuation among callers, which worsens the maintenability.
> >
> > One difficulty of code sharing is that the callers want to determine
> > whether they try to walk over a specific vma or not in their own way.
> > To solve this, this patch introduces test_walk() callback.
> >
> > When we try to use multiple callbacks in different levels, skip control is
> > also important. For example we have thp enabled in normal configuration, and
> > we are interested in doing some work for a thp. But sometimes we want to
> > split it and handle as normal pages, and in another time user would handle
> > both at pmd level and pte level.
> > What we need is that when we've done pmd_entry() we want to decide whether
> > to go down to pte level handling based on the pmd_entry()'s result. So this
> > patch introduces a skip control flag in mm_walk.
> > We can't use the returned value for this purpose, because we already
> > defined the meaning of whole range of returned values (>0 is to terminate
> > page table walk in caller's specific manner, =0 is to continue to walk,
> > and <0 is to abort the walk in the general manner.)
> >
> > ...
> >
> > --- v3.13-rc3-mmots-2013-12-10-16-38.orig/mm/pagewalk.c
> > +++ v3.13-rc3-mmots-2013-12-10-16-38/mm/pagewalk.c
> > @@ -3,29 +3,49 @@
> > #include
> > #include
> >
> > -static int walk_pte_range(pmd_t *pmd, unsigned long addr, unsigned long
> > end,
> > - struct mm_walk *walk)
> > +static bool skip_check(struct mm_walk *walk)
> > {
> > + if (walk->skip) {
> > + walk->skip = 0;
> > + return true;
> > + }
> > + return false;
> > +}
>
> It would be nice to have some more documentation around this "skip"
> thing, either here or at its definition site. When and why is it set,
> what role does it perform, why is it reset after first being tested, etc.
I wrote some comment about skip in the comment walk_page_range(),
but I'll add more to clarify things.
Here what I mean by skip is to skip lower level walking, and that was
determined for each entry independently. For example, when walk_pmd_range
handles a pmd_trans_huge we don't have to walk over ptes under that pmd,
and the skipping does not affect the walking over ptes under other pmds.
That's why we reset skip after tested.
> skip_check() is misnamed - it does more than "check" - it also resets
> the field! I can't think of a better name though - skip_check_once()?
> skip_check_and_reset()? Perhaps the name should reflect the function's
> operation at a higher semantic level, but without a description of what
> that is, I con't suggest...
So skip_lower_level_walking() might be good.
> > +static int walk_pte_range(pmd_t *pmd, unsigned long addr,
> > + unsigned long end, struct mm_walk *walk)
> > +{
> > + struct mm_struct *mm = walk->mm;
> > pte_t *pte;
> > + pte_t *orig_pte;
> > + spinlock_t *ptl;
> > int err = 0;
> >
> > - pte = pte_offset_map(pmd, addr);
> > - for (;;) {
> > + orig_pte = pte = pte_offset_map_lock(mm, pmd, addr, );
> > + do {
> > + if (pte_none(*pte)) {
> > + if (walk->pte_hole)
> > + err = walk->pte_hole(addr, addr + PAGE_SIZE,
> > + walk);
> > + if (err)
> > + break;
> > + continue;
> > + }
> > + /*
> > +* Callers should have their own way to handle swap entries
> > +* in walk->pte_entry().
> > +*/
> > err = walk->pte_entry(pte, addr, addr + PAGE_SIZE, walk);
> > if (err)
> >break;
> > - addr += PAGE_SIZE;
> > - if (addr == end)
> > - break;
> > - pte++;
> > - }
> > -
> > - pte_unmap(pte);
> > - return err;
> > + } while (pte++, addr += PAGE_SIZE, addr < end);
> > + pte_unmap_unlock(orig_pte, ptl);
> > + cond_resched();
>
> Is that cond_resched() a new thing?
No. Currently some caller use
Re: [PATCH v4]vt: use vc_allocate in con_init
On Wed, Jan 08, 2014 at 07:13:10AM +0800, Wang YanQing wrote:
> After a5f4f52e82114e85aa1a066bd1a450acc19a464d
> ("vt: use kzalloc() instead of the bootmem allocator"),
> con_init began to use kzalloc to initialize vc_data,
> this patch convert con_init to use vc_allocate.
>
> The benefit we get:
> 1: reduce code duplication
> 2: vc_allocate is more robust
> 3: use kmalloc instead of kzalloc for vc_screenbuf
>
> Signed-off-by: Wang YanQing
> ---
> this patch don't have v2 :) I jump to v3 directly
> from v1, but I keep the mistake for less confusion.
>
> Changes v3-v4:
> 1: use bool/true/false instead of int/1/0
>
> Thanks for Jiri Slaby
>
> drivers/tty/vt/vt.c | 28 ++--
> drivers/tty/vt/vt_ioctl.c | 8
> include/linux/vt_kern.h | 2 +-
> 3 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 15aaa01..c0d6255 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -748,7 +748,8 @@ static void visual_init(struct vc_data *vc, int num, int
> init)
> vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row;
> }
>
> -int vc_allocate(unsigned int currcons) /* return 0 on success */
> +/* return 0 on success */
> +int vc_allocate(unsigned int currcons, bool early)
What does "early" mean? I understand the goal of making the code
smaller (hint, it's the same size overall with this change), but adding
flags like this just makes things a whole lot harder to debug and
understand later on.
I really don't like this as it adds to the programmer's complexity at
the tradeoff of a chance at smaller code.
sorry,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2]vt: fix potential dual con_driver register for conswitchp
On Mon, Dec 30, 2013 at 11:21:18AM +0800, Wang YanQing wrote: > We should check whether conswitchp is registered before > add it to registered_con_driver in con_init, or it will > cause dual con_driver register for conswitchp. > > Although I haven't met it in reality, but I think it could > happen for Embeded devices, who register platform con_driver > earlier than call con_init. Does that happen on those systems? Let's not add code that's never going to be use, and is not needed, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vt: initialize con_driver->node in con_init
On Mon, Dec 30, 2013 at 11:11:02AM +0800, Wang YanQing wrote:
> Commit 6db4063c5b72b46e9793b0f141a7a3984ac6facf
> ("[PATCH] VT binding: Add sysfs control to the VT layer")
> add node item into struct con_driver.
That patch was from 2006. Why is this change needed now, what problems
happen without your fix below?
thanks,
greg k-h
>
> This patch initialize con_driver->node in con_init.
>
> Signed-off-by: Wang YanQing
> ---
> drivers/tty/vt/vt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index edcd6b8..9adb4e0 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -2879,6 +2879,7 @@ static int __init con_init(void)
> if (con_driver->con == NULL) {
> con_driver->con = conswitchp;
> con_driver->desc = display_desc;
> + con_driver->node = i;
> con_driver->flag = CON_DRIVER_FLAG_INIT;
> con_driver->first = 0;
> con_driver->last = MAX_NR_CONSOLES - 1;
> --
> 1.8.3.4.8.g69490f3.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] crypto:s5p-sss: Exynos5 SoCs too can select SSS driver
Hello Tomasz, On 8 January 2014 06:00, Tomasz Figa wrote: > On Tuesday 07 of January 2014 17:21:48 Naveen Krishna Ch wrote: >> This patch modifies Kconfig such that ARCH_EXYNOS5 SoCs >> can also select Samsung SSS(Security SubSystem) driver. >> >> Signed-off-by: Naveen Krishna Ch >> CC: Herbert Xu >> CC: David S. Miller >> CC: Vladimir Zapolskiy >> TO: >> CC: >> --- >> drivers/crypto/Kconfig |8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig >> index f4fd837..137dcd8 100644 >> --- a/drivers/crypto/Kconfig >> +++ b/drivers/crypto/Kconfig >> @@ -300,15 +300,15 @@ config CRYPTO_DEV_DCP >> capabilities of the DCP co-processor >> >> config CRYPTO_DEV_S5P >> - tristate "Support for Samsung S5PV210 crypto accelerator" >> - depends on ARCH_S5PV210 >> + tristate "Support for Samsung crypto accelerator" >> + depends on ARCH_S5PV210 || ARCH_EXYNOS5 >> select CRYPTO_AES >> select CRYPTO_ALGAPI >> select CRYPTO_BLKCIPHER >> help >> This option allows you to have support for S5P crypto acceleration. >> - Select this to offload Samsung S5PV210 or S5PC110 from AES >> - algorithms execution. >> + Select this to offload Samsung S5PV210 or S5PC110, Exynos5250 >> + and Exynos5420 from AES algorithms execution. > > What about Exynos4 SoCs? The SSS module as such looks alike on Exynos5250, Exynso5420 and Exynos4210. I couldn't test it right now. I should also verify on other Exynos4 SoCs. > > Best regards, > Tomasz > -- Shine bright, (: Nav :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] ARM: exynos5420: add dt node for sss module
Hello Tomasz,
On 8 January 2014 06:02, Tomasz Figa wrote:
> On Tuesday 07 of January 2014 17:21:49 Naveen Krishna Ch wrote:
>> From: Naveen Krishna Chatradhi
>>
>> this patch adds the device tree nodes for SSS module found on Exynos5420
>
> nit: Sentences in English start with a capital letter. Also this patch
> adds one node, not few of them as the description suggests.
>
> Also patch subject should start with ARM: dts: prefix.
>
>>
>> Signed-off-by: Naveen Krishna Chatradhi
>> TO:
>> CC: Kukjin Kim
>> CC:
>> ---
>> arch/arm/boot/dts/exynos5420.dtsi | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
>> b/arch/arm/boot/dts/exynos5420.dtsi
>> index 11dd202..97045f9 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -652,4 +652,14 @@
>> clocks = < 319>, < 318>;
>> clock-names = "tmu_apbif", "tmu_triminfo_apbif";
>> };
>> +
>> + sss: sss {
>
> Node name should be sss@1083 as per ePAPR node naming recommendation.
Thanks for the correction, Will correct it and submit. Thanks
>
> Best regards,
> Tomasz
>
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Idle power fix regresses ebizzy performance (was 3.12-stable backport of NUMA balancing patches)
On Wed, Jan 08, 2014 at 01:48:58PM +, Mel Gorman wrote: > Adding LKML to the list as this -stable snifftest has identified an > upstream regression. > > On Wed, Jan 08, 2014 at 10:43:40AM +, Mel Gorman wrote: > > On Tue, Jan 07, 2014 at 08:30:12PM +, Mel Gorman wrote: > > > On Tue, Jan 07, 2014 at 10:54:40AM -0800, Greg KH wrote: > > > > On Tue, Jan 07, 2014 at 06:17:15AM -0800, Greg KH wrote: > > > > > On Tue, Jan 07, 2014 at 02:00:35PM +, Mel Gorman wrote: > > > > > > A number of NUMA balancing patches were tagged for -stable but I > > > > > > got a > > > > > > number of rejected mails from either Greg or his robot minion. The > > > > > > list > > > > > > of relevant patches is > > > > > > > > > > > > FAILED: patch "[PATCH] mm: numa: serialise parallel get_user_page > > > > > > against THP" > > > > > > FAILED: patch "[PATCH] mm: numa: call MMU notifiers on THP > > > > > > migration" > > > > > > MERGED: Patch "mm: clear pmd_numa before invalidating" > > > > > > FAILED: patch "[PATCH] mm: numa: do not clear PMD during PTE update > > > > > > scan" > > > > > > FAILED: patch "[PATCH] mm: numa: do not clear PTE for pte_numa > > > > > > update" > > > > > > MERGED: Patch "mm: numa: ensure anon_vma is locked to prevent > > > > > > parallel THP splits" > > > > > > MERGED: Patch "mm: numa: avoid unnecessary work on the failure path" > > > > > > MERGED: Patch "sched: numa: skip inaccessible VMAs" > > > > > > FAILED: patch "[PATCH] mm: numa: clear numa hinting information on > > > > > > mprotect" > > > > > > FAILED: patch "[PATCH] mm: numa: avoid unnecessary disruption of > > > > > > NUMA hinting during" > > > > > > Patch "mm: fix TLB flush race between migration, and > > > > > > change_protection_range" > > > > > > Patch "mm: numa: guarantee that tlb_flush_pending updates are > > > > > > visible before page table updates" > > > > > > FAILED: patch "[PATCH] mm: numa: defer TLB flush for THP migration > > > > > > as long as" > > > > > > > > > > > > Fixing the rejects one at a time may cause other conflicts due to > > > > > > ordering > > > > > > issues. Instead, this patch series against 3.12.6 is the full list > > > > > > of > > > > > > backported patches in the expected order. Greg, unfortunately this > > > > > > means > > > > > > you may have to drop some patches already in your stable tree and > > > > > > reapply > > > > > > but on the plus side they should be then in the correct order for > > > > > > bisection > > > > > > purposes and you'll know I've tested this combination of patches. > > > > > > > > > > Many thanks for these, I'll go queue them up in a bit and drop the > > > > > others to ensure I got all of this correct. > > > > > > > > Ok, I've now queued all of these up, in this order, so we should be > > > > good. > > > > > > > > I'll do a -rc2 in a bit as it needs some testing. > > > > > > > > > > Thanks a million. I should be cc'd on some of those so I'll pick up the > > > final result and run it through the same tests just to be sure. > > > > > > > Ok, tests completed and look more or less as expected. This is not to > > say the performance results are *good* as such. Workloads that normally > > demonstrate automatic numa balancing suffered because of other patches that > > were merged (primarily fair zone allocation policy) that had interesting > > side-effects. However, it now does not crash under heavy stress and I > > prefer working a little slowly than crashing fast. NAS at least looks > > better. > > > > Other workloads like kernel builds, page fault microbench looked good as > > expected from the fair zone allocation policy fixes. > > > > Big downside is that ebizzy performance is *destroyed* in that RC2 patch > > somewhere > > > > ebizzy > > 3.12.63.12.63.12.7-rc2 > > vanilla backport-v1r2 stablerc2 > > Mean 1 3278.67 ( 0.00%) 3180.67 ( -2.99%) 3212.00 ( -2.03%) > > Mean 2 2322.67 ( 0.00%) 2294.67 ( -1.21%) 1839.00 (-20.82%) > > Mean 3 2257.00 ( 0.00%) 2218.67 ( -1.70%) 1664.00 (-26.27%) > > Mean 4 2268.00 ( 0.00%) 2224.67 ( -1.91%) 1629.67 (-28.15%) > > Mean 5 2247.67 ( 0.00%) 2255.67 ( 0.36%) 1582.33 (-29.60%) > > Mean 6 2263.33 ( 0.00%) 2251.33 ( -0.53%) 1547.67 (-31.62%) > > Mean 7 2273.67 ( 0.00%) .67 ( -2.24%) 1545.67 (-32.02%) > > Mean 8 2254.67 ( 0.00%) 2232.33 ( -0.99%) 1535.33 (-31.90%) > > Mean 12 2237.67 ( 0.00%) 2266.33 ( 1.28%) 1543.33 (-31.03%) > > Mean 16 2201.33 ( 0.00%) 2252.67 ( 2.33%) 1540.33 (-30.03%) > > Mean 20 2205.67 ( 0.00%) 2229.33 ( 1.07%) 1537.33 (-30.30%) > > Mean 24 2162.33 ( 0.00%) 2168.67 ( 0.29%) 1535.33 (-29.00%) > > Mean 28 2139.33 ( 0.00%) 2107.67 ( -1.48%) 1535.00 (-28.25%) > > Mean 32 2084.67 (
Re: [GIT PULL] extcon next for 3.14
On Thu, Jan 09, 2014 at 11:02:24AM +0900, Chanwoo Choi wrote: > Dear Greg, > > This is extcon-next full request for v3.14. I add detailed description of this > pull request on below. Please pull extcon with following updates. > > This patchset is rebased on 'Linux 3-13-rc4' because char-misc-next is based > on > 'Linux 3-13-rc4'. > > Best Regards, > Chanwoo Choi > > The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d: > > Linux 3.13-rc4 (2013-12-15 12:31:33 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git > tags/extcon-next-for-3.14 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 0/4] PHY: for 3.14
On Thu, Dec 26, 2013 at 10:17:16PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > here's the patches for 3.14. It contains few fixes on phy-core and added a new > PHY driver used by SATA in Marvell SoCs. > > Let me know if you need any changes. > > Thanks > Kishon > > The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: > > Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git > tags/for_3.14 Pulled and pushed out, sorry for the delay. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with the btrfs tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
fs/btrfs/extent_io.c between commit 1c94f854cbb6 ("btrfs: remove unused
variables from extent_io.c") from the btrfs tree and commit 2c30c71bd653
("block: Convert various code to bio_for_each_segment()") from the block
tree.
I fixed it up (thanks Chris for the heads up and resolution - see below)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/btrfs/extent_io.c
index fbe501d3bd01,bcb6f1b780d6..
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@@ -2375,12 -2332,15 +2375,13 @@@ int end_extent_writepage(struct page *p
*/
static void end_bio_extent_writepage(struct bio *bio, int err)
{
- struct bio_vec *bvec = bio->bi_io_vec + bio->bi_vcnt - 1;
+ struct bio_vec *bvec;
- struct extent_io_tree *tree;
u64 start;
u64 end;
+ int i;
- do {
+ bio_for_each_segment_all(bvec, bio, i) {
struct page *page = bvec->bv_page;
- tree = _I(page->mapping->host)->io_tree;
/* We always issue full-page reads, but if some block
* in a page fails to read, blk_update_request() will
pgpj6ZWPJSYfX.pgp
Description: PGP signature
Re: [PATCH] ARM: imx6q: Add missing esai_ahb clock to current clock tree
On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > static struct clk *clk[clk_max];
> > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node
> > *ccm_node)
> > clk[ecspi5] = imx_clk_gate2("ecspi5","ecspi_root",
> > base + 0x6c, 8);
> > clk[enet] = imx_clk_gate2("enet", "ipg",
> > base + 0x6c, 10);
> > clk[esai] = imx_clk_gate2("esai", "esai_podf",
> > base + 0x6c, 16);
> > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb",
> > base + 0x6c, 16);
>
> Hmm, having two clocks operating on the same gate bit will get us
> problem in clock disabling. Clock enabling is fine, since either
> one who calls clk_enable() first will just set the gate bit. But in
> case that clk_enable() is called on both clocks, and then when either
> clock calls clk_disable(), the gate bit will be cleared and thus breaks
> the other one that might still be in use.
Understood. But how could we handle this situation? The only way I can figure
out is to make sure the driver open/close them at the same time, it's not a
perfect way though.
Nicolin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver
On 01/08/2014 07:47 PM, joeyli wrote: > > Unfortunately current acpica leaks the SystemCMOS handler: > > ACPI Error: Region SystemCMOS (ID=5) has no handler (20131115/exfldio-299) > I'm sorry, I can't parse either your statement or the error message... sounds like there is a bug here, too. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: imx6q: Add missing esai_ahb clock to current clock tree
On Thu, Jan 09, 2014 at 11:04:59AM +0800, Nicolin Chen wrote:
> esai_ahb clock is derived from ahb and used to provide ESAI the capability of
> register accessing and FSYS clock source for I2S clocks dividing. Although the
> gate of this esai_ahb is duplicated with esai clock -- the baud clock, yet
> considering about the differences of their clock rates, it's quite essential
> to patch this missing clock.
>
> Signed-off-by: Nicolin Chen
> ---
> Documentation/devicetree/bindings/clock/imx6q-clock.txt | 1 +
> arch/arm/mach-imx/clk-imx6q.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> index 6aab72b..90ec91f 100644
> --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
> @@ -220,6 +220,7 @@ clocks and IDs.
> lvds2_sel 205
> lvds1_gate 206
> lvds2_gate 207
> + esai_ahb208
>
> Examples:
>
> diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
> index af2e582..20215b9 100644
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -107,7 +107,7 @@ enum mx6q_clks {
> sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref,
> usbphy1_gate,
> usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
> spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, pll4_audio_div,
> - lvds1_sel, lvds2_sel, lvds1_gate, lvds2_gate, clk_max
> + lvds1_sel, lvds2_sel, lvds1_gate, lvds2_gate, esai_ahb, clk_max
> };
>
> static struct clk *clk[clk_max];
> @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node
> *ccm_node)
> clk[ecspi5] = imx_clk_gate2("ecspi5","ecspi_root",
> base + 0x6c, 8);
> clk[enet] = imx_clk_gate2("enet", "ipg",
> base + 0x6c, 10);
> clk[esai] = imx_clk_gate2("esai", "esai_podf",
> base + 0x6c, 16);
> + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb",
> base + 0x6c, 16);
Hmm, having two clocks operating on the same gate bit will get us
problem in clock disabling. Clock enabling is fine, since either
one who calls clk_enable() first will just set the gate bit. But in
case that clk_enable() is called on both clocks, and then when either
clock calls clk_disable(), the gate bit will be cleared and thus breaks
the other one that might still be in use.
Shawn
> clk[gpt_ipg] = imx_clk_gate2("gpt_ipg", "ipg",
> base + 0x6c, 20);
> clk[gpt_ipg_per] = imx_clk_gate2("gpt_ipg_per", "ipg_per",
> base + 0x6c, 22);
> if (cpu_is_imx6dl())
> --
> 1.8.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] spi: atmel: Refactor spi-atmel to use SPI framework queue
Hi Richard, > -Original Message- > From: Richard Genoud [mailto:richard.gen...@gmail.com] > Sent: Wednesday, January 08, 2014 6:26 PM > To: Yang, Wenyou > Cc: broo...@kernel.org; Ferre, Nicolas; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH] spi: atmel: Refactor spi-atmel to use SPI framework > queue > > On 08/01/2014 06:49, Wenyou Yang wrote: > > Replace the deprecated master->transfer with transfer_one_message() > > and allow the SPI subsystem handle all the queuing of messages. > > > > Signed-off-by: Wenyou Yang > > --- > > Hi Mark, > > > > The patch is based on for-next branch of > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git > > > > It is tested on sama5d3xek and at91sam9m10g45ek board. > > And the bug I was seeing with SPI_IOC_MESSAGE (cf > https://lkml.org/lkml/2013/10/8/269 ) is now gone ! > > Tested on at91sam9g35-ek > > Tested-by: Richard Genoud > Thanks a lot for your testing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 04/14] ACPI: Add ACPI 5.0 Time and Alarm Device driver
於 三，2014-01-08 於 09:56 -0800，H. Peter Anvin 提到： [...] > > Document of Windows XP: > > > http://www.freelists.org/post/windows_errors/what-error-messages-really-mean-WinXP-IO-Ports-Blocked-from-Bios-AML-on-Windows-XP > > > > If just for ACPI TAD testing, we can remove the port protection > check of > > RTC ports in hwvalid.c. I have read 0x70/0x71 port success after > removed > > the checking in acpica/hwvalid.c. > > > > I will try to write RTC port in AML after remove acpica check, maybe > > have other unpredictable situation. > > > > Now *THERE* is a good use of the "no RTC bit". In the case that bit > is > set we should presumably remove these ports from the block list. Thanks for your suggestion, I will put a testing patch on this. > > Otherwise we should use the CMOS address space, not the I/O port > address > space. > > -hpa Unfortunately current acpica leaks the SystemCMOS handler: ACPI Error: Region SystemCMOS (ID=5) has no handler (20131115/exfldio-299) Regards Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc] perf on raspberry-pi without overflow interrupt
On Wed, 8 Jan 2014, Peter Zijlstra wrote:
> On Wed, Jan 08, 2014 at 04:28:20PM -0500, Vince Weaver wrote:
> > Should the perf_event interface handle setups like this better and work
> > fine in aggregate mode but return ENOTSUP if a sampled or overflow event
> > is attempted?
>
> Yeah that would be better, we do something similar for P6 class machines
> without lapic IIRC.
You're right. Something like the following works for me on the rasp-pi,
although maybe if x86 is doing it too things should be moved up into
generic code?
---
Return EOPNOTSUPP if we have no PMU overflow interrupt but a
sampled event is requested.
Signed-off-by: Vince Weaver
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index f24edad..f1f27a3 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -87,6 +87,7 @@ struct arm_pmu {
u64 max_period;
struct platform_device *plat_device;
struct pmu_hw_events*(*get_hw_events)(void);
+ int no_overflow_interrupt;
};
#define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index bc3f2ef..fa4ecc3 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -397,7 +397,7 @@ __hw_perf_event_init(struct perf_event *event)
*/
hwc->config_base|= (unsigned long)mapping;
- if (!hwc->sample_period) {
+ if (!is_sampling_event(event)) {
/*
* For non-sampling runs, limit the sample_period to half
* of the counter width. That way, the new counter value
@@ -407,6 +407,12 @@ __hw_perf_event_init(struct perf_event *event)
hwc->sample_period = armpmu->max_period >> 1;
hwc->last_period= hwc->sample_period;
local64_set(>period_left, hwc->sample_period);
+ } else {
+ /*
+* If we have no PMU interrupt we cannot sample
+*/
+ if (armpmu->no_overflow_interrupt)
+ return -EOPNOTSUPP;
}
if (event->group_leader != event) {
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index d85055c..a74e0cd 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -97,8 +97,9 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu,
irq_handler_t handler)
irqs = min(pmu_device->num_resources, num_possible_cpus());
if (irqs < 1) {
- pr_err("no irqs for PMUs defined\n");
- return -ENODEV;
+ printk_once("no irqs for PMUs defined, emulating with
hrtimer\n");
+ cpu_pmu->no_overflow_interrupt=1;
+ return 0;
}
for (i = 0; i < irqs; ++i) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the sound-asoc tree with the tree
Hi all,
Today's linux-next merge of the sound-asoc tree got a conflict in
sound/soc/fsl/fsl_ssi.c between commit 0da9e55e71bc ("ASoC: fsl_ssi: Add
dual fifo mode support") from the slave-dma tree and commit c1953bfe1329
("ASoC: fsl-ssi: Add imx51-ssi and of_device_id matching") and
0888efd166fa ("ASoC: fsl-ssi: Fix interrupt stats for imx") from the
sound-asoc tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc sound/soc/fsl/fsl_ssi.c
index 2101fc5c5739,94dedcb0868d..
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@@ -140,8 -162,9 +162,10 @@@ struct fsl_ssi_private
bool ssi_on_imx;
bool imx_ac97;
bool use_dma;
+ bool use_dual_fifo;
bool baudclk_locked;
+ bool irq_stats;
+ bool offline_config;
u8 i2s_mode;
spinlock_t baudclk_lock;
struct clk *baudclk;
@@@ -1170,8 -1332,35 +1348,35 @@@ static int fsl_ssi_probe(struct platfor
ssi_private->baudclk_locked = false;
spin_lock_init(_private->baudclk_lock);
- if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx21-ssi")) {
+ /*
+* imx51 and later SoCs have a slightly different IP that allows the
+* SSI configuration while the SSI unit is running.
+*
+* More important, it is necessary on those SoCs to configure the
+* sperate TX/RX DMA bits just before starting the stream
+* (fsl_ssi_trigger). The SDMA unit has to be configured before fsl_ssi
+* sends any DMA requests to the SDMA unit, otherwise it is not defined
+* how the SDMA unit handles the DMA request.
+*
+* SDMA units are present on devices starting at imx35 but the imx35
+* reference manual states that the DMA bits should not be changed
+* while the SSI unit is running (SSIEN). So we support the necessary
+* online configuration of fsl-ssi starting at imx51.
+*/
+ switch (hw_type) {
+ case FSL_SSI_MCP8610:
+ case FSL_SSI_MX21:
+ case FSL_SSI_MX35:
+ ssi_private->offline_config = true;
+ break;
+ case FSL_SSI_MX51:
+ ssi_private->offline_config = false;
+ break;
+ }
+
+ if (hw_type == FSL_SSI_MX21 || hw_type == FSL_SSI_MX51 ||
+ hw_type == FSL_SSI_MX35) {
- u32 dma_events[2];
+ u32 dma_events[2], dmas[4];
ssi_private->ssi_on_imx = true;
ssi_private->clk = devm_clk_get(>dev, NULL);
@@@ -1234,16 -1424,13 +1440,22 @@@
dma_events[0], shared ? IMX_DMATYPE_SSI_SP :
IMX_DMATYPE_SSI);
imx_pcm_dma_params_init_data(_private->filter_data_rx,
dma_events[1], shared ? IMX_DMATYPE_SSI_SP :
IMX_DMATYPE_SSI);
+ if (!of_property_read_u32_array(pdev->dev.of_node, "dmas",
dmas, 4)
+ && dmas[2] == IMX_DMATYPE_SSI_DUAL) {
+ ssi_private->use_dual_fifo = true;
+ /* When using dual fifo mode, we need to keep watermark
+ * as even numbers due to dma script limitation.
+ */
+ ssi_private->dma_params_tx.maxburst &= ~0x1;
+ ssi_private->dma_params_rx.maxburst &= ~0x1;
+ }
- } else if (ssi_private->use_dma) {
+ }
+
+ /*
+* Enable interrupts only for MCP8610 and MX51. The other MXs have
+* different writeable interrupt status registers.
+*/
+ if (ssi_private->use_dma) {
/* The 'name' should not have any slashes in it. */
ret = devm_request_irq(>dev, ssi_private->irq,
fsl_ssi_isr, 0, ssi_private->name,
pgprrs35iGTNU.pgp
Description: PGP signature
Re: [GIT PULL 0/4] PHY: for 3.14
On Wed, Jan 08, 2014 at 10:54:13AM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > On Thursday 26 December 2013 10:17 PM, Kishon Vijay Abraham I wrote: > > Hi Greg, > > > > here's the patches for 3.14. It contains few fixes on phy-core and added a > > new > > PHY driver used by SATA in Marvell SoCs. > > > > Let me know if you need any changes. > > > > Thanks > > Kishon > > > > The following changes since commit 413541dd66d51f791a0b169d9b9014e4f56be13c: > > > > Linux 3.13-rc5 (2013-12-22 13:08:32 -0800) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git > > tags/for_3.14 > > > > for you to fetch changes up to e3eae85773ebd2165d19ca8661cca3b9c60b2ba1: > > > > Phy: Add a PHY driver for Marvell MVEBU SATA PHY. (2013-12-24 23:52:58 > > +0530) > > > > > > Pull request for PHY subsystem contains few fixes in PHY-CORE mostly > > w.r.t PM and reference counting and also a new PHY driver used by SATA > > in Marvell SoC. > > > > > > Andrew Lunn (1): > > Phy: Add a PHY driver for Marvell MVEBU SATA PHY. > > > > Felipe Balbi (1): > > phy: core: properly handle failure of pm_runtime_get functions > > > > Kishon Vijay Abraham I (2): > > phy: phy-core: increment refcounting variables only on 'success' > > phy: phy-core.c: remove unnecessary initialization of local variables\ > > > Will you be taking these patches? Yes, sorry, catching up from my vacation backlog... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kdump failed because of hotplug memory adding in kdump kernel
On 01/09/14 at 12:07am, Rafael J. Wysocki wrote: > On Wednesday, January 08, 2014 10:58:29 AM Vivek Goyal wrote: > > On Wed, Jan 08, 2014 at 11:26:43PM +0800, Baoquan wrote: > > > > [..] > > > [1.59] acpi PNP0A03:03: fail to add MMCONFIG information, can't > > > access extended PCI configuration space under this bridge. > > > [1.605045] PCI host bridge to bus :ff > > > [1.609615] pci_bus :ff: root bus resource [bus ff] > > > [1.632117] System RAM resource [mem 0x0100-0x7bff] cannot be > > > added > > > [1.639892] init_memory_mapping: [mem 0x1-0x87fff] > > > [1.717793] swapper/0: page allocation failure: order:9, mode:0x84d0 > > > [1.724884] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > > > 3.10.0-59.el7.x86_64 #1 > > > [1.732842] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS > > > QSSC-S4R.QCI.01.00.S001.032520101647 03/25/2010 > > > [1.743224] 8800339878c8 815b64ad > > > 880033987950 > > > [1.751513] 8113a980 88003673ab28 01fe > > > 0001 > > > [1.759804] 8840 810bc28a > > > 0200 > > > [1.768096] Call Trace: > > > > > > [348/1928] > > > [1.770834] [] dump_stack+0x19/0x1b > > > [1.776561] [] warn_alloc_failed+0xf0/0x160 > > > [1.783076] [] ? on_each_cpu_mask+0x2a/0x60 > > > [1.789581] [] __alloc_pages_nodemask+0x7ff/0xa00 > > > [1.796672] [] vmemmap_alloc_block+0x62/0xba > > > [1.803274] [] vmemmap_alloc_block_buf+0x15/0x3b > > > [1.810263] [] vmemmap_populate+0xb4/0x21b > > > [1.816673] [] sparse_mem_map_populate+0x27/0x35 > > > [1.823665] [] sparse_add_one_section+0x7a/0x185 > > > [1.830659] [] __add_pages+0xaf/0x240 > > > [1.836588] [] arch_add_memory+0x59/0xd0 > > > [1.842804] [] add_memory+0xb9/0x1b0 > > > [1.848638] [] acpi_memory_device_add+0x18d/0x26d > > > [1.855728] [] acpi_bus_device_attach+0x7d/0xcd > > > [1.862625] [] acpi_ns_walk_namespace+0xc8/0x17f > > > [1.869616] [] ? acpi_bus_type_and_status+0x90/0x90 > > > [1.876896] [] ? acpi_bus_type_and_status+0x90/0x90 > > > [1.884177] [] acpi_walk_namespace+0x95/0xc5 > > > [1.890780] [] acpi_bus_scan+0x8b/0x9d > > > [1.896805] [] acpi_scan_init+0x63/0x160 > > > [1.903021] [] acpi_init+0x25d/0x2a6 > > > > So basically acpi thinks that some memory block is a hot plug memory > > and tries to add it. And that consumes lots of memory and we don't have > > that memory in second kernel. > > That's not exactly the case. What seems to happen is that there is an ACPI > memory object in the ACPI namespace and the ACPI memory hotplug driver > attempts to bind to it. That driver attempts to find removable memory blocks > associated with that object and to add them to the memory map. Yeah, since kdump kernel will detect rsdp for legacy machine in the first 1K of the EBDA or between E and F. > > Why don't you simply append acpi=off to the kexec command line? That should > make the problem go away. acpi=off doesn't work, kdump kernel hang immediately after crash is triggered. Because acpi information is needed by kdump kernel, we can't disable it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch Part2 V1 07/14] iommu/vt-d: fix error in detect ATS capability
This is a issue, our BIOS also supports several ATSR which have the same segment. Good fix :) On 2014/1/7 17:00, Jiang Liu wrote: > Current Intel IOMMU driver only matches a PCIe root port with the first > DRHD unit with the samge segment number. It will report false result > if there are multiple DRHD units with the same segment number, thus fail > to detect ATS capability for some PCIe devices. > > This patch refines function dmar_find_matched_atsr_unit() to search all > DRHD units with the same segment number. > > An example DMAR table entries as below: > [1D0h 0464 2]Subtable Type : 0002 > [1D2h 0466 2] Length : 0028 > [1D4h 0468 1]Flags : 00 > [1D5h 0469 1] Reserved : 00 > [1D6h 0470 2] PCI Segment Number : > > [1D8h 0472 1] Device Scope Entry Type : 02 > [1D9h 0473 1] Entry Length : 08 > [1DAh 0474 2] Reserved : > [1DCh 0476 1] Enumeration ID : 00 > [1DDh 0477 1] PCI Bus Number : 00 > [1DEh 0478 2] PCI Path : [02, 00] > > [1E0h 0480 1] Device Scope Entry Type : 02 > [1E1h 0481 1] Entry Length : 08 > [1E2h 0482 2] Reserved : > [1E4h 0484 1] Enumeration ID : 00 > [1E5h 0485 1] PCI Bus Number : 00 > [1E6h 0486 2] PCI Path : [03, 00] > > [1E8h 0488 1] Device Scope Entry Type : 02 > [1E9h 0489 1] Entry Length : 08 > [1EAh 0490 2] Reserved : > [1ECh 0492 1] Enumeration ID : 00 > [1EDh 0493 1] PCI Bus Number : 00 > [1EEh 0494 2] PCI Path : [03, 02] > > [1F0h 0496 1] Device Scope Entry Type : 02 > [1F1h 0497 1] Entry Length : 08 > [1F2h 0498 2] Reserved : > [1F4h 0500 1] Enumeration ID : 00 > [1F5h 0501 1] PCI Bus Number : 00 > [1F6h 0502 2] PCI Path : [03, 03] > > [1F8h 0504 2]Subtable Type : 0002 > [1FAh 0506 2] Length : 0020 > [1FCh 0508 1]Flags : 00 > [1FDh 0509 1] Reserved : 00 > [1FEh 0510 2] PCI Segment Number : > > [200h 0512 1] Device Scope Entry Type : 02 > [201h 0513 1] Entry Length : 08 > [202h 0514 2] Reserved : > [204h 0516 1] Enumeration ID : 00 > [205h 0517 1] PCI Bus Number : 40 > [206h 0518 2] PCI Path : [02, 00] > > [208h 0520 1] Device Scope Entry Type : 02 > [209h 0521 1] Entry Length : 08 > [20Ah 0522 2] Reserved : > [20Ch 0524 1] Enumeration ID : 00 > [20Dh 0525 1] PCI Bus Number : 40 > [20Eh 0526 2] PCI Path : [02, 02] > > [210h 0528 1] Device Scope Entry Type : 02 > [211h 0529 1] Entry Length : 08 > [212h 0530 2] Reserved : > [214h 0532 1] Enumeration ID : 00 > [215h 0533 1] PCI Bus Number : 40 > [216h 0534 2] PCI Path : [03, 00] > > [218h 0536 2]Subtable Type : 0002 > [21Ah 0538 2] Length : 0020 > [21Ch 0540 1]Flags : 00 > [21Dh 0541 1] Reserved : 00 > [21Eh 0542 2] PCI Segment Number : > > [220h 0544 1] Device Scope Entry Type : 02 > [221h 0545 1] Entry Length : 08 > [222h 0546 2] Reserved : > [224h 0548 1] Enumeration ID : 00 > [225h 0549 1] PCI Bus Number : 80 > [226h 0550 2] PCI Path : [02, 00] > > [228h 0552 1] Device Scope Entry Type : 02 > [229h 0553 1] Entry Length : 08 > [22Ah 0554 2] Reserved : > [22Ch 0556 1] Enumeration ID : 00 > [22Dh 0557 1] PCI Bus Number : 80 > [22Eh 0558 2] PCI Path : [02, 02] > > [230h 0560 1] Device Scope Entry Type : 02 > [231h 0561 1] Entry Length : 08 > [232h 0562 2] Reserved : > [234h 0564 1] Enumeration ID : 00 > [235h 0565 1] PCI Bus Number : 80 > [236h 0566 2] PCI Path : [03, 00] > > [238h 0568 2]Subtable Type : 0002 > [23Ah 0570 2] Length : 0020 > [23Ch 0572 1]Flags : 00 > [23Dh 0573 1] Reserved : 00 > [23Eh 0574 2] PCI Segment Number : > > [240h 0576 1] Device Scope Entry Type : 02 > [241h 0577 1] Entry Length : 08 > [242h 0578 2] Reserved : > [244h 0580 1] Enumeration ID
[PATCH] ARM: imx6q: Add missing esai_ahb clock to current clock tree
esai_ahb clock is derived from ahb and used to provide ESAI the capability of
register accessing and FSYS clock source for I2S clocks dividing. Although the
gate of this esai_ahb is duplicated with esai clock -- the baud clock, yet
considering about the differences of their clock rates, it's quite essential
to patch this missing clock.
Signed-off-by: Nicolin Chen
---
Documentation/devicetree/bindings/clock/imx6q-clock.txt | 1 +
arch/arm/mach-imx/clk-imx6q.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 6aab72b..90ec91f 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -220,6 +220,7 @@ clocks and IDs.
lvds2_sel 205
lvds1_gate 206
lvds2_gate 207
+ esai_ahb208
Examples:
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index af2e582..20215b9 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -107,7 +107,7 @@ enum mx6q_clks {
sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref,
usbphy1_gate,
usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, pll4_audio_div,
- lvds1_sel, lvds2_sel, lvds1_gate, lvds2_gate, clk_max
+ lvds1_sel, lvds2_sel, lvds1_gate, lvds2_gate, esai_ahb, clk_max
};
static struct clk *clk[clk_max];
@@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[ecspi5] = imx_clk_gate2("ecspi5","ecspi_root",
base + 0x6c, 8);
clk[enet] = imx_clk_gate2("enet", "ipg",
base + 0x6c, 10);
clk[esai] = imx_clk_gate2("esai", "esai_podf",
base + 0x6c, 16);
+ clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb",
base + 0x6c, 16);
clk[gpt_ipg] = imx_clk_gate2("gpt_ipg", "ipg",
base + 0x6c, 20);
clk[gpt_ipg_per] = imx_clk_gate2("gpt_ipg_per", "ipg_per",
base + 0x6c, 22);
if (cpu_is_imx6dl())
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/regmap.h: fix a couple of typos
On 01/08/14 17:46, Laszlo Papp wrote: > On Wed, Jan 8, 2014 at 9:49 PM, Mark Brown wrote: >> On Wed, Jan 08, 2014 at 09:08:44PM +, Laszlo Papp wrote: >>> On Wed, Jan 8, 2014 at 9:02 PM, Laszlo Papp wrote: >> That being said, I will not have time, nor the motivation to argue over such a nuance, so feel free to reject the change. >> >>> Of course, this is just on top of the vim spell checker error as I >>> wrote in the commit message... >> >>> Oh yes, and one more factual data in here: >> >>> lpapp ~/Projects/linux-staging $ grep -rn "e\.g\." . | wc -l >>> 3447 >> >>> lpapp ~/Projects/linux-staging $ grep -rn " eg," | wc -l >>> 18 >> >> That's not the issue - it's dropping the comma. It's either "e.g." or >> "eg", the comma is a separate thing providing a break between clauses. >> Strictly it should have the periods since it is an abbreviation but >> their use is more vauge in fixed point text since they look ugly, the >> thing that made me complain was that you dropped the comma as well as >> substituting in the expanded version. > > I still do not get what point you are trying to make. Could you please > provide evidence? Because really, this is the usage I have seen in > projects out there all around, including the majority of the linux > kernel. > > Here is some more data: > > grep -rn "e\.g\. " . | wc -l > 2553 > lpapp ~/Projects/linux-staging $ grep -rn "e\.g\.," . | wc -l > 573 > -- Hi, I am used to seeing e.g. and i.e. always followed by a comma when they are used to begin a sentence. However, I just checked and some online style guides say to omit the comma and some say to use it, and we (Linux kernel) don't really have a writing style guide to look at. I think that makes it up to the maintainer to decide what is acceptable. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the ipsec-next tree with the net-next tree
Hi Steffen,
Today's linux-next merge of the ipsec-next tree got a conflict in
net/xfrm/xfrm_policy.c between commits be7928d20bab ("net: xfrm:
xfrm_policy: fix inline not at beginning of declaration") and
da7c224b1baa ("net: xfrm: xfrm_policy: silence compiler warning") from
the net-next tree and commit 2f3ea9a95c58 ("xfrm: checkpatch erros with
inline keyword position") from the ipsec-next tree.
I fixed it up (I used the version from the net-next tree) and can carry
the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp8y3ztlCP5b.pgp
Description: PGP signature
Re: [RFC] mm: prevent set a value less than 0 to min_free_kbytes
On Wed, 8 Jan 2014, Han Pingtian wrote: > If echo -1 > /proc/vm/sys/min_free_kbytes, the system will hang. > Changing proc_dointvec() to proc_dointvec_minmax() in the > min_free_kbytes_sysctl_handler() can prevent this to happen. > > Signed-off-by: Han Pingtian Acked-by: David Rientjes Nice catch! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: slub: fix ALLOC_SLOWPATH stat
On Mon, 6 Jan 2014, Dave Hansen wrote: > There used to be only one path out of __slab_alloc(), and > ALLOC_SLOWPATH got bumped in that exit path. Now there are two, > and a bunch of gotos. ALLOC_SLOWPATH can now get set more than once > during a single call to __slab_alloc() which is pretty bogus. > Here's the sequence: > > 1. Enter __slab_alloc(), fall through all the way to the >stat(s, ALLOC_SLOWPATH); > 2. hit 'if (!freelist)', and bump DEACTIVATE_BYPASS, jump to >new_slab (goto #1) > 3. Hit 'if (c->partial)', bump CPU_PARTIAL_ALLOC, goto redo >(goto #2) > 4. Fall through in the same path we did before all the way to >stat(s, ALLOC_SLOWPATH) > 5. bump ALLOC_REFILL stat, then return > > Doing this is obviously bogus. It keeps us from being able to > accurately compare ALLOC_SLOWPATH vs. ALLOC_FASTPATH. It also > means that the total number of allocs always exceeds the total > number of frees. > > This patch moves stat(s, ALLOC_SLOWPATH) to be called from the > same place that __slab_alloc() is. This makes it much less > likely that ALLOC_SLOWPATH will get botched again in the > spaghetti-code inside __slab_alloc(). > > Signed-off-by: Dave Hansen Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/7] mfd: ssbi: Add regmap read/write helpers
On 01/08/14 17:13, Courtney Cavin wrote:
> On Wed, Jan 08, 2014 at 07:37:47PM +0100, Stephen Boyd wrote:
>> --- a/include/linux/ssbi.h
>> +++ b/include/linux/ssbi.h
>> @@ -20,4 +20,17 @@
>> int ssbi_write(struct device *dev, u16 addr, const u8 *buf, int len);
>> int ssbi_read(struct device *dev, u16 addr, u8 *buf, int len);
>>
>> +static inline int
>> +ssbi_reg_read(void *context, unsigned int reg, unsigned int *val)
>> +{
>> +*val = 0;
>> +return ssbi_read(context, reg, (u8 *)val, 1);
>> +}
>> +
>> +static inline int
>> +ssbi_reg_write(void *context, unsigned int reg, unsigned int val)
>> +{
>> +return ssbi_write(context, reg, (u8 *), 1);
>> +}
> These functions are endian specific and just generally ugly. I
> understand that these functions may make the ssbi regmap code cleaner,
> but that's not really a good excuse for functions which by themselves
> look horribly broken.
>
> If these are really needed, perhaps something like the following would
> be acceptable?
>
> +static inline int
> +ssbi_reg_read(void *context, unsigned int reg, unsigned int *val)
> +{
> + int rc;
> + u8 b;
> + rc = ssbi_read(context, reg, , 1);
> + if (rc == 1)
> + *val = b;
> + return rc;
> +}
> +
> +static inline int
> +ssbi_reg_write(void *context, unsigned int reg, unsigned int val)
> +{
> + u8 b = val;
> + return ssbi_write(context, reg, , 1);
> +}
Sure. I think you meant to check for a 0 return value from ssbi_read
though? Lee can you use this replacement patch please?
---8<---
From: Stephen Boyd
Subject: [PATCH] mfd: ssbi: Add regmap read/write helpers
Add read and write helper functions that the pm8921-core driver
can use to read and write ssbi regsiters via a "no-bus" regmap.
Cc: Mark Brown
Signed-off-by: Stephen Boyd
---
include/linux/ssbi.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/ssbi.h b/include/linux/ssbi.h
index bcbb642a7641..087b08a4d333 100644
--- a/include/linux/ssbi.h
+++ b/include/linux/ssbi.h
@@ -20,4 +20,24 @@
int ssbi_write(struct device *dev, u16 addr, const u8 *buf, int len);
int ssbi_read(struct device *dev, u16 addr, u8 *buf, int len);
+static inline int
+ssbi_reg_read(void *context, unsigned int reg, unsigned int *val)
+{
+ int ret;
+ u8 v;
+
+ ret = ssbi_read(context, reg, , 1);
+ if (!ret)
+ *val = v;
+
+ return ret;
+}
+
+static inline int
+ssbi_reg_write(void *context, unsigned int reg, unsigned int val)
+{
+ u8 v = val;
+ return ssbi_write(context, reg, , 1);
+}
+
#endif
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] slub: Fix possible format string bug.
On Sat, 4 Jan 2014, Tetsuo Handa wrote: > The "name" is determined at runtime and is parsed as format string. > > Signed-off-by: Tetsuo Handa Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iscsi: fix wrong order of opcode and itt in iscsi_handle_reject prompt
This patch makes reject messages show right value for opcode and itt, which is converse previously. Signed-off-by: Vaughan Cao --- drivers/scsi/libiscsi.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c index e399561..27547ff 100644 --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -1013,13 +1013,13 @@ static int iscsi_handle_reject(struct iscsi_conn *conn, struct iscsi_hdr *hdr, iscsi_conn_printk(KERN_ERR, conn, "pdu (op 0x%x itt 0x%x) rejected " "due to DataDigest error.\n", - rejected_pdu.itt, opcode); + opcode, rejected_pdu.itt); break; case ISCSI_REASON_IMM_CMD_REJECT: iscsi_conn_printk(KERN_ERR, conn, "pdu (op 0x%x itt 0x%x) rejected. Too many " "immediate commands.\n", - rejected_pdu.itt, opcode); + opcode, rejected_pdu.itt); /* * We only send one TMF at a time so if the target could not * handle it, then it should get fixed (RFC mandates that @@ -1059,8 +1059,8 @@ static int iscsi_handle_reject(struct iscsi_conn *conn, struct iscsi_hdr *hdr, default: iscsi_conn_printk(KERN_ERR, conn, "pdu (op 0x%x itt 0x%x) rejected. Reason " - "code 0x%x\n", rejected_pdu.itt, - rejected_pdu.opcode, reject->reason); + "code 0x%x\n", rejected_pdu.opcode, + rejected_pdu.itt, reject->reason); break; } return rc; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: MAX6650/6651 support
On Wed, Jan 8, 2014 at 10:39 PM, Lee Jones wrote:
>> MAX6650/MAX6651 chip is a multi-function device with I2C busses. The
>> chip includes fan-speed regulators and monitors, GPIO, and alarm.
>>
>> This patch is an initial release of a MAX6650/6651 MFD driver that
>> supports to enable the chip with its primary I2C bus that will connect
>> the hwmon, and then the gpio devices for now.
>>
>> Signed-off-by: Laszlo Papp
>> ---
>> drivers/mfd/Kconfig | 11 +++
>> drivers/mfd/Makefile| 1 +
>> drivers/mfd/max6651.c | 132
>>
>> include/linux/mfd/max6651-private.h | 53 +++
>> 4 files changed, 197 insertions(+)
>> create mode 100644 drivers/mfd/max6651.c
>> create mode 100644 include/linux/mfd/max6651-private.h
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index dd67158..706c4e5 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -321,6 +321,17 @@ config MFD_88PM860X
>> select individual components like voltage regulators, RTC and
>> battery-charger under the corresponding menus.
>>
>> +config MFD_MAX6651
>> + bool "Maxim Semiconductor MAX6651 Support"
>> + depends on I2C=y
>> + select MFD_CORE
>> + select IRQ_DOMAIN
>
> Why have you selected IRQ_DOMAIN?
Initial consistency with other corresponding drivers, but I should
have dropped it once I dropped the irq handling to be as simple as
possible initially.
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> Are you sure all these are used? I'm pretty sure some of them are
> not. Only add headers if you require them. Try not to copy and paste
> stuff you don't need.
Yes, this was meant to be the "final clean up step". I aimed
functionality and design first.
>> +#include
>> +
>> +static struct mfd_cell max6651_devs[] = {
>> +{ .name = "max6651-gpio", },
>> +{ .name = "max6650", },
>
> It would be nice to have a comment here to indicate that this is a
> hwmon driver. If you're planning to add support for the MAX6651 to
> this existing driver,
Actually, it is already renamed to max6650-hwmon in the next patch of
this series.
> also consider renaming it to "max665x".
Hmm, I will consider.
>> +};
>> +
>> +int max6651_read_reg(struct i2c_client *i2c, u8 reg, u8 *dest)
>> +{
>
> Probably best to use Regmap instead.
>
> regmap_i2c_read()
Yes, do not worry, this was already done after Linus' initial comment.
Note that, it will be a bit hackish to get it working with 3.2 where
the device regmap convenience wrapper was missing, but I guess
backporting is my problem, not yours...
>> +struct max6651_dev *max6651 = i2c_get_clientdata(i2c);
>> +int ret;
>
> Always use 8 char tabs for kernel code.
As discussed, style stuff is not fixed for a design review. I am still
intereted in having an automated fix-up like astyle in other projects?
What is the recommended way? I really would not like to waste too much
time with style clean up.
>> +mutex_lock(>iolock);
>> +ret = i2c_smbus_read_byte_data(i2c, reg);
>> +mutex_unlock(>iolock);
>> +if (ret < 0)
>> +return ret;
>> +
>> +ret &= 0xff;
>> +*dest = ret;
>
> *dest = ret & 0xff is clear enough.
I think this function would be removed altogether instead.
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(max6651_read_reg);
>> +
>> +int max6651_write_reg(struct i2c_client *i2c, u8 reg, u8 value)
>> +{
>> +struct max6651_dev *max6651 = i2c_get_clientdata(i2c);
>> +int ret;
>
> Same here.
>
> regmap_i2c_write()
See above.
>> +mutex_lock(>iolock);
>> +ret = i2c_smbus_write_byte_data(i2c, reg, value);
>> +mutex_unlock(>iolock);
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(max6651_write_reg);
>> +
>> +static int max6651_i2c_probe(struct i2c_client *i2c,
>> + const struct i2c_device_id *id)
>> +{
>> + struct max6651_dev *max6651;
>> + int ret = 0;
>
> Why are you initialising ret?
Habit for striving for good pratice, I think. It may have also been
consitency. That being said, I already removed it when I took a look
at the other driver based on Linus' suggestion. I was trying to be
consistent with other maxim drivers.
The linux kernel drivers are inconsistent in general at large,
unfortunately. It is hard to pick up the "right one" for consistency.
I will do whatever asked as it really does not make any difference for
me.
>> + max6651 = kzalloc(sizeof(struct max6651_dev), GFP_KERNEL);
>
> Use managed resources devm_*.
Yes, that was also done after Linus' suggestion.
> s/sizeof(struct max6651_dev)/sizeof(*max6651)/
>
>> + if (max6651 == NULL)
>
> if (!max6651)
Yes, that was also done after Linus' suggestion, although this is
consistent with the other maxim drivers. I will refactor those
later...
>> + return -ENOMEM;
>> +
>> + i2c_set_clientdata(i2c, max6651);
>> +
Re: [PATCH v4 02/15] clk: Allow drivers to pass in a regmap
On 01/08/14 17:51, Mike Turquette wrote:
> Quoting Stephen Boyd (2013-12-23 17:12:26)
>> Add support to the clock core so that drivers can pass in a
>> regmap. If no regmap is specified try to query the device that's
>> registering the clock for its regmap. This should allow drivers
>> to use the core regmap helpers. This is based on a similar design
>> in the regulator framework.
>>
>> Cc: Mark Brown
>> Signed-off-by: Stephen Boyd
>> ---
>> drivers/clk/clk.c| 8
>> include/linux/clk-provider.h | 7 +++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 9ad7b71..5e71f5c 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> static DEFINE_SPINLOCK(enable_lock);
>> static DEFINE_MUTEX(prepare_lock);
>> @@ -1834,6 +1835,13 @@ static int _clk_register(struct device *dev, struct
>> clk_hw *hw, struct clk *clk)
>> clk->num_parents = hw->init->num_parents;
>> hw->clk = clk;
>>
>> + if (hw->init->regmap)
>> + hw->regmap = hw->init->regmap;
> Hi Stephen,
>
> The whole series looks good to me except for the placement of the regmap
> details inside struct clk_hw. That structure exists only to hide struct
> clk from the hardware-specific clock structure and I'd not like to set
> the precedent of shoving per-clock data into it.
>
> As an alternative, how about finding a way to put these per-clock regmap
> details into the hardware-specific clock structure? I understand that
> you want to make these ops available to others, which is why they are in
> the public struct clk_hw. I'm just wondering if that is the right way to
> do it...
The regulator framework has gone this way. It seemed like a similar
approach in the clock framework would be the right way to go too.
>
> Patch #3 illustrates the sort of struct-member-creep that worries me.
> What is to stop someone from putting "unsigned int divider_reg" or
> "unsigned int mux_reg", and then the thing just keeps growing.
>
I see two ways forward if you don't want these members in struct clk_hw.
1) Inheritance: struct clk_regmap wrapper struct and
clk_register_regmap() and devm_clk_register_regmap() and then another
wrapper struct around that.
example:
struct clk_regmap {
struct clk_hw hw;
struct regmap *regmap;
unsigned int enable_reg;
unsigned int enable_mask;
bool enable_is_inverted;
};
struct clk_branch {
u32 hwcg_reg;
u32 halt_reg;
u8 hwcg_bit;
u8 halt_bit;
u8 halt_check;
struct clk_regmap clkr;
};
static struct clk_branch gsbi1_uart_clk = {
.halt_reg = 0x2fcc,
.halt_bit = 10,
.clkr = {
.enable_reg = 0x29d4,
.enable_mask = BIT(9),
.hw.init = &(struct clk_init_data){
.name = "gsbi1_uart_clk",
.parent_names = (const char *[]){
"gsbi1_uart_src",
},
.num_parents = 1,
.ops = _branch_ops,
.flags = CLK_SET_RATE_PARENT,
},
},
};
2) Interfaces: Add a void *data in struct clk_hw that can point to
whatever I want and still have the same clk_regmap_register() and
devm_clk_regmap_register()
Example:
struct clk_hw {
struct clk *clk;
const struct clk_init_data *init;
void *data;
};
struct clk_regmap {
struct regmap *regmap;
unsigned int enable_reg;
unsigned int enable_mask;
bool enable_is_inverted;
};
struct clk_branch {
u32 hwcg_reg;
u32 halt_reg;
u8 hwcg_bit;
u8 halt_bit;
u8 halt_check;
struct clk_hw;
};
static struct clk_branch gsbi1_uart_clk = {
.halt_reg = 0x2fcc,
.halt_bit = 10,
.hw = {
.data = &(struct clk_regmap){
.enable_reg = 0x29d4,
.enable_mask = BIT(9),
};
.init = &(struct clk_init_data){
.name = "gsbi1_uart_clk",
.parent_names = (const char *[]){
"gsbi1_uart_src",
},
.num_parents = 1,
.ops = _branch_ops,
.flags = CLK_SET_RATE_PARENT,
},
},
};
I guess option 2 is less likely given your comment about clk_hw being
nothing more than a traversal mechanism.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[GIT PULL] extcon next for 3.14
Dear Greg, This is extcon-next full request for v3.14. I add detailed description of this pull request on below. Please pull extcon with following updates. This patchset is rebased on 'Linux 3-13-rc4' because char-misc-next is based on 'Linux 3-13-rc4'. Best Regards, Chanwoo Choi The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d: Linux 3.13-rc4 (2013-12-15 12:31:33 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-3.14 for you to fetch changes up to 6544dfa5795060b01042fd62fd1a92e18c2fc485: extcon: gpio: Add power resume support (2014-01-09 09:53:30 +0900) Update extcon for v3.14 This patchset add new driver of extcon-max14577.c which detect various external connector and fix minor issue of extcon provider driver(extcon-arizona/palams/ gpio.c). Also, update documentation of previous 'switch' porting guide and extcon git repository url. Detailed description for patchset: - New driver of extcon-max14577.c : Add extcon-max14577.c drvier to support Maxim MUIC(Micro USB Interface Controller) which detect USB/TA/JIG/AUDIO-DOCK and additional accessory according to each resistance when connected external connector. - extcon-arizoan.c driver : Code clean to use define macro instead of hex value : Fix minor issue to reset back to our staring state : Fix race with microphone detection and removal - extcon-palmas.c driver : Fix minor issue and renaming compatible string of Devicetree - extcon-gpio.c driver : Fix bug about ordering initialization of gpio pin on probe() : Send uevent after wakeup from suspend state because some SoC haven't wakeup interrupt on suspend state. - Documentation (Documentation/extcon/porting-android-switch-class) : Fix switch class porting guide - Update extcon git repository url Chanwoo Choi (2): MAINTAINERS: Add git repository for extcon extcon: max14577: Add extcon-max14577 driver to support MUIC device Charles Keepax (5): extcon: arizona: Add defines for microphone detection levels extcon: arizona: Fix reset of HPDET after race with removal extcon: arizona: Fix race with microphone detection and removal extcon: arizona: No need to switch back down HPDET ranges extcon: arizona: Add support for headphone detection on wm5110 rev D George Cherian (1): extcon: palmas: Handle ID interrupt properly using USB_ID_INT_SRC Guenter Roeck (1): extcon: gpio: Request gpio pin before modifying its state Kishon Vijay Abraham I (1): extcon: palmas: Added a new compatible type *ti,palmas-usb-vid* MyungJoo Ham (1): extcon: fix switch class porting guide (Documentation) Rongjun Ying (1): extcon: gpio: Add power resume support .../devicetree/bindings/extcon/extcon-palmas.txt | 6 +- Documentation/extcon/porting-android-switch-class | 9 +- MAINTAINERS| 1 + drivers/extcon/Kconfig | 10 + drivers/extcon/Makefile| 1 + drivers/extcon/extcon-arizona.c| 73 +- drivers/extcon/extcon-gpio.c | 32 +- drivers/extcon/extcon-max14577.c | 752 + drivers/extcon/extcon-palmas.c | 17 +- include/linux/extcon/extcon-gpio.h | 1 + include/linux/mfd/arizona/registers.h | 9 + 11 files changed, 876 insertions(+), 35 deletions(-) create mode 100644 drivers/extcon/extcon-max14577.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] perf tools: Make the print_pmu_events funtion to return unsigned int.
On 01/08/2014 10:10 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, Dec 30, 2013 at 10:26:37AM -0500, Dongsheng Yang escreveu:
Sometimes we need to know how many events have been printed in print_pmu_events.
"Sometimes" is too vague, of course it should be needed, otherwise why
bother with the patch? It would be better if you provided an example of
_where_ it will be used, like when printing that newline.
Sorry for the terrible commit message :(.
What about the following one?
"When we call print_pmu_events(), we want to know how many events has
been printed in this function. But currently it is impossible, as it
return void.
This patch change this function to return the number of events we have
printed."
- Yang
Anyway, reading the other patches,
- Arnaldo
This patch make this function to return the number of events we have printed.
Signed-off-by: Dongsheng Yang
---
tools/perf/util/pmu.c | 12 +++-
tools/perf/util/pmu.h | 2 +-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 0934d64..331dc2c 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -711,12 +711,12 @@ static int cmp_string(const void *a, const void *b)
return strcmp(*as, *bs);
}
-void print_pmu_events(const char *event_glob, bool name_only)
+unsigned int print_pmu_events(const char *event_glob, bool name_only)
{
struct perf_pmu *pmu;
struct perf_pmu_alias *alias;
char buf[1024];
- int printed = 0;
+ unsigned int count = 0;
int len, j;
char **aliases;
@@ -727,7 +727,7 @@ void print_pmu_events(const char *event_glob, bool name_only)
len++;
aliases = malloc(sizeof(char *) * len);
if (!aliases)
- return;
+ return count;
pmu = NULL;
j = 0;
while ((pmu = perf_pmu__scan(pmu)) != NULL)
@@ -752,15 +752,17 @@ void print_pmu_events(const char *event_glob, bool
name_only)
for (j = 0; j < len; j++) {
if (name_only) {
printf("%s ", aliases[j]);
+ count++;
continue;
}
printf(" %-50s [Kernel PMU event]\n", aliases[j]);
zfree([j]);
- printed++;
+ count++;
}
- if (printed)
+ if (count)
printf("\n");
free(aliases);
+ return count;
}
bool pmu_have_event(const char *pname, const char *name)
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 9183380..2987fe2 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -42,7 +42,7 @@ int perf_pmu__format_parse(char *dir, struct list_head *head);
struct perf_pmu *perf_pmu__scan(struct perf_pmu *pmu);
-void print_pmu_events(const char *event_glob, bool name_only);
+unsigned int print_pmu_events(const char *event_glob, bool name_only);
bool pmu_have_event(const char *pname, const char *name);
int perf_pmu__test(void);
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH Trivial] intel-iommu: check return value of device_to_iommu() before using it
in function iommu_support_dev_iotlb(),return value of device_to_iommu() is used without checking, this could cause NULL pointer issue. this patch is for v3.12.6 Signed-off-by: Ethan Zhao --- drivers/iommu/intel-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 40203ad..5b4531a 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -1105,6 +1105,8 @@ static struct device_domain_info *iommu_support_dev_iotlb( struct device_domain_info *info; struct intel_iommu *iommu = device_to_iommu(segment, bus, devfn); +if (!iommu) +return NULL; if (!ecap_dev_iotlb_support(iommu->ecap)) return NULL; -- 1.7.1 >From 27d8cdd3fcc6f4ff5cc2ba36d8d5ea0a97823a17 Mon Sep 17 00:00:00 2001 From: ethan.zhao Date: Thu, 9 Jan 2014 08:40:16 -0500 Subject: [PATCH] intel-iommu: check return value of device_to_iommu() before using it in function iommu_support_dev_iotlb(),return value of device_to_iommu() is used without checking, this could cause NULL pointer issue. this patch is for v3.12.6 Signed-off-by: Ethan Zhao --- drivers/iommu/intel-iommu.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 40203ad..5b4531a 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -1105,6 +1105,8 @@ static struct device_domain_info *iommu_support_dev_iotlb( struct device_domain_info *info; struct intel_iommu *iommu = device_to_iommu(segment, bus, devfn); + if (!iommu) + return NULL; if (!ecap_dev_iotlb_support(iommu->ecap)) return NULL; -- 1.7.1
Re: [PATCH 3/8] perf tools: free aliases[j] in pmu.c if name_only is true.
On 01/08/2014 10:12 AM, Arnaldo Carvalho de Melo wrote:
What for? Please be clear in the changelogs, it helps with review.
Now I'll have to follow the logic to figure this out, i.e. _why_ we
should free aliases[j] if name_only is true? Is it safe?
Sorry for my lazy on the changelogs here :(.
As aliases is a 2-D array malloced in function print_pmu_events(), we
should free it after printf. But we just did it when (!name_only).
This patch fix the leak error in print_pmu_events() when name_only is true.
I will update the commit message in next version.
- Yang
- Arnaldo
Em Mon, Dec 30, 2013 at 10:26:38AM -0500, Dongsheng Yang escreveu:
Signed-off-by: Dongsheng Yang
---
tools/perf/util/pmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 331dc2c..169c480 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -752,6 +752,7 @@ unsigned int print_pmu_events(const char *event_glob, bool
name_only)
for (j = 0; j < len; j++) {
if (name_only) {
printf("%s ", aliases[j]);
+ zfree([j]);
count++;
continue;
}
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/6] ARM: Add Krait L2 accessor functions
On 01/08/14 16:53, Courtney Cavin wrote: > On Mon, Dec 30, 2013 at 09:14:14PM +0100, Stephen Boyd wrote: >> Krait CPUs have a handful of L2 cache controller registers that >> live behind a cp15 based indirection register. First you program >> the indirection register (l2cpselr) to point the L2 'window' >> register (l2cpdr) at what you want to read/write. Then you >> read/write the 'window' register to do what you want. The >> l2cpselr register is not banked per-cpu so we must lock around >> accesses to it to prevent other CPUs from re-pointing l2cpdr >> underneath us. >> >> Cc: Mark Rutland >> Cc: Russell King >> Signed-off-by: Stephen Boyd >> --- >> arch/arm/common/Kconfig | 3 ++ >> arch/arm/common/Makefile | 1 + >> arch/arm/common/krait-l2-accessors.c | 58 >> +++ >> arch/arm/include/asm/krait-l2-accessors.h | 20 +++ >> 4 files changed, 82 insertions(+) >> create mode 100644 arch/arm/common/krait-l2-accessors.c >> create mode 100644 arch/arm/include/asm/krait-l2-accessors.h > [...] >> + >> +extern void set_l2_indirect_reg(u32 addr, u32 val); >> +extern u32 get_l2_indirect_reg(u32 addr); > As these are Krait specific, please rename the functions to reflect > this. > Ok. Borislav, should I resend to add krait_ before these functions? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V6 0/4] perf/x86/amd: AMD Family 16h Data Breakpoint Extensions
Hi Suravee, On Wed, Jan 08, 2014 at 01:00:36PM -0600, Suravee Suthikulanit wrote: > Ping. Are there any other concerns regarding this patch? > > Thank you, > > Suravee The patches look good. I'll apply the series and propose it to the perf maintainers. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/9] CPU enable method based SMP/hotplug + MSM conversion
On 01/08/14 13:37, Arnd Bergmann wrote: > On Tuesday 24 December 2013, Stephen Boyd wrote: >> This is a rework of patches sent a months back by Rohit[1]. >> The goal of these patches is to add support for SMP and (basic) >> hotplug on MSM based SoCs. To get there, we add support for a >> generic way to hook in SMP/hotplug support code based on DT. To >> show how it's used, we convert the MSM8660 SMP support code over >> to the new method. After that we add support for the rest of the >> upstream MSM SoCs (note these patches are piled high on top of >> Rohit's patches to add 8074 support to MSM[2] and my follow ups[3,4], >> but this should only matter to the MSM maintainers). >> >> This is one of the last items of code that still requires us to have >> a mach directory and a machine descriptor. We should be able to move >> the hotplug/smp code out of mach directories if this approach is >> accepted. > The implementation looks ok to me, but I wonder whether on a global > scale we want to tie it more closely to the cpuidle implementations. > We already have a drivers/cpuidle framework, and while I admit > that I'm not familiar with the code in there, I would assume that > the smp operations and the cpuidle code usually go hand in hand. Sure. Right now the smp ops code is fairly well tied into the arch layer so it sounds like there is some future work when we move this stuff out of the mach directory. Would arm-soc be able to pick these patches up for 3.14? I think everything is in place for these patches now that Mark has reviewed them. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] include/linux/regmap.h: fix a couple of typos
On Wed, Jan 8, 2014 at 9:49 PM, Mark Brown wrote: > On Wed, Jan 08, 2014 at 09:08:44PM +, Laszlo Papp wrote: >> On Wed, Jan 8, 2014 at 9:02 PM, Laszlo Papp wrote: > >> > That being said, I will not have time, nor the motivation to argue >> > over such a nuance, so feel free to reject the change. > >> Of course, this is just on top of the vim spell checker error as I >> wrote in the commit message... > >> Oh yes, and one more factual data in here: > >> lpapp ~/Projects/linux-staging $ grep -rn "e\.g\." . | wc -l >> 3447 > >> lpapp ~/Projects/linux-staging $ grep -rn " eg," | wc -l >> 18 > > That's not the issue - it's dropping the comma. It's either "e.g." or > "eg", the comma is a separate thing providing a break between clauses. > Strictly it should have the periods since it is an abbreviation but > their use is more vauge in fixed point text since they look ugly, the > thing that made me complain was that you dropped the comma as well as > substituting in the expanded version. I still do not get what point you are trying to make. Could you please provide evidence? Because really, this is the usage I have seen in projects out there all around, including the majority of the linux kernel. Here is some more data: grep -rn "e\.g\. " . | wc -l 2553 lpapp ~/Projects/linux-staging $ grep -rn "e\.g\.," . | wc -l 573 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the libata tree with the pci tree
Hi Tejun,
Today's linux-next merge of the libata tree got a conflict in
drivers/ata/ahci.c between commit 7b92b4f61ec4 ("PCI/MSI: Remove
pci_enable_msi_block_auto()") from the pci tree and commit d93414513966
("drivers: ata: Mark the function ahci_init_interrupts() as static in
ahci.c") from the libata tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/ata/ahci.c
index 3cf6dad71e11,74911c2cb1dd..
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@@ -1097,40 -1148,26 +1148,40 @@@ static inline void ahci_gtf_filter_work
{}
#endif
- int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
-static int ahci_init_interrupts(struct pci_dev *pdev, struct ahci_host_priv
*hpriv)
++static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
{
- int rc;
- unsigned int maxvec;
+ int rc, nvec;
- if (!(hpriv->flags & AHCI_HFLAG_NO_MSI)) {
- rc = pci_enable_msi_block_auto(pdev, );
- if (rc > 0) {
- if ((rc == maxvec) || (rc == 1))
- return rc;
- /*
- * Assume that advantage of multipe MSIs is negated,
- * so fallback to single MSI mode to save resources
- */
- pci_disable_msi(pdev);
- if (!pci_enable_msi(pdev))
- return 1;
- }
- }
+ if (hpriv->flags & AHCI_HFLAG_NO_MSI)
+ goto intx;
+
+ rc = pci_msi_vec_count(pdev);
+ if (rc < 0)
+ goto intx;
+
+ /*
+ * If number of MSIs is less than number of ports then Sharing Last
+ * Message mode could be enforced. In this case assume that advantage
+ * of multipe MSIs is negated and use single MSI mode instead.
+ */
+ if (rc < n_ports)
+ goto single_msi;
+
+ nvec = rc;
+ rc = pci_enable_msi_block(pdev, nvec);
+ if (rc)
+ goto intx;
+ return nvec;
+
+single_msi:
+ rc = pci_enable_msi(pdev);
+ if (rc)
+ goto intx;
+ return 1;
+
+intx:
pci_intx(pdev, 1);
return 0;
}
pgpOVDtbszCBR.pgp
Description: PGP signature
[PATCH 0/3] mmc: rtsx: fix bug and support nonblocking request
From: Micky Ching First we fix the card poweroff bug: the card power is not shutdown when sd/mmc card removed, this will make UHS-card failed to running in high speed mode if we insert the card again. We offer a concise tuning searching method, it is much easier to read. At last we add support for nonblocking request, which will improve card read speed at about 10% write speed about 5% normally. Micky Ching (3): mmc: rtsx: fix card poweroff bug mmc: rtsx: modify phase searching method for tuning mmc: rtsx: add support for pre_req and post_req drivers/mfd/rtsx_pcr.c| 132 ++--- drivers/mmc/host/rtsx_pci_sdmmc.c | 537 ++--- include/linux/mfd/rtsx_common.h |1 + include/linux/mfd/rtsx_pci.h |8 +- 4 files changed, 481 insertions(+), 197 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation: spelling
On Wed, Jan 8, 2014 at 9:44 PM, Randy Dunlap wrote: > On 01/08/14 13:11, Laszlo Papp wrote: >> On Wed, Jan 8, 2014 at 6:54 PM, Randy Dunlap wrote: >>> On 01/08/2014 08:31 AM, Laszlo Papp wrote: Hi, which spelling is preferred for the documentation when sending patches? I see the UK'ish "initialise" as well as the US'ish "initialization" within the same close to each other. >>> >>> >>> We accept either UK or US spellings. >>> >>> It would be nice to be consistent within one document, but about all >>> that we can count on is for one person to be consistent most of the >>> time. >>> >>> -- >>> ~Randy >> >> Thanks Randy! >> >> So, does that mean if I fix grammar or typo issues in a file, I should >> also fix the UK'ish terms by replacing them with the US'ish when both >> types are occurring? > > I would say the fewer "trivial" changes, the better, so don't change them > if they are correct in either spelling. Strange, but ok, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] perf tools: Improve the message of perf list for unexpected input.
On 01/08/2014 10:16 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, Dec 30, 2013 at 10:26:39AM -0500, Dongsheng Yang escreveu:
Example:
# perf list test
List of pre-defined events (to be used in -e):
# echo $?
0
Verification:
# perf list test
No event for test.
?
Are we "testing" events?
The message is not clear, I can get some info from looking at the Usage,
but not from 'No event for test'.
At a minimum 'test' (whatevet invalid type/class is specified and found
to be invalid/unknown) should be quoted.
Perhaps the message should be along the lines of:
# perf list test
'test' is not a valid event type, please see the usage below for
acceptable ones.
Makes sense. I will update it.
Usage:
perf list [hw|sw|cache|tracepoint|pmu|event_glob]
# echo $?
255
Signed-off-by: Dongsheng Yang
---
tools/perf/builtin-list.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 011195e..fed6792 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -19,6 +19,7 @@
int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
{
int i;
+ unsigned int count = 0;
const struct option list_options[] = {
OPT_END()
};
@@ -41,26 +42,27 @@ int cmd_list(int argc, const char **argv, const char
*prefix __maybe_unused)
if (i)
putchar('\n');
if (strncmp(argv[i], "tracepoint", 10) == 0)
- print_tracepoint_events(NULL, NULL, false);
+ count += print_tracepoint_events(NULL, NULL, false);
else if (strcmp(argv[i], "hw") == 0 ||
strcmp(argv[i], "hardware") == 0)
- print_events_type(PERF_TYPE_HARDWARE);
+ count += print_events_type(PERF_TYPE_HARDWARE);
else if (strcmp(argv[i], "sw") == 0 ||
strcmp(argv[i], "software") == 0)
- print_events_type(PERF_TYPE_SOFTWARE);
+ count += print_events_type(PERF_TYPE_SOFTWARE);
else if (strcmp(argv[i], "cache") == 0 ||
strcmp(argv[i], "hwcache") == 0)
- print_hwcache_events(NULL, false);
+ count += print_hwcache_events(NULL, false);
else if (strcmp(argv[i], "pmu") == 0)
- print_pmu_events(NULL, false);
+ count += print_pmu_events(NULL, false);
else if (strcmp(argv[i], "--raw-dump") == 0)
- print_events(NULL, true);
+ count += print_events(NULL, true);
else {
char *sep = strchr(argv[i], ':'), *s;
int sep_idx;
if (sep == NULL) {
- print_events(argv[i], false);
+ if(!(count += print_events(argv[i], false)))
+ goto err_out;
continue;
}
sep_idx = sep - argv[i];
@@ -69,9 +71,16 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
return -1;
s[sep_idx] = '\0';
- print_tracepoint_events(s, s + sep_idx + 1, false);
+ if (!(count += print_tracepoint_events(s, s + sep_idx +
1, false)))
+ goto err_out;
free(s);
}
}
+
return 0;
+
+err_out:
+ pr_info("\nNo event for %s.\n", argv[i]);
+ pr_info("Usage:\n\t%s\n", list_usage[0]);
+ return -1;
}
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
