Re: [PATCH v10 12/13] drm/mediatek: update DSI sub driver flow for sending commands to panel
Hi, YT:
some comments inline.
On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
>
> Signed-off-by: shaoming chen
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 101
> +
> 1 file changed, 80 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index ded4202..0569f2e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -126,6 +126,10 @@
> #define CLK_HS_POST (0xff << 8)
> #define CLK_HS_EXIT (0xff << 16)
>
> +#define DSI_VM_CMD_CON 0x130
> +#define VM_CMD_ENBIT(0)
> +#define TS_VFP_ENBIT(5)
> +
> #define DSI_CMDQ00x180
> #define CONFIG (0xff << 0)
> #define SHORT_PACKET 0
> @@ -249,7 +253,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>* mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
>* we set mipi_ratio is 1.05.
>*/
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + dsi->data_rate = dsi->vm.pixelclock * 12 * 21;
> + dsi->data_rate /= (dsi->lanes * 1000 * 10);
This looks like a bug fix that use lanes to calculate data rate.
> + DRM_DEBUG_DRIVER("set mipitx's data rate: %dMHz\n", dsi->data_rate);
>
> ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 100);
> if (ret < 0) {
> @@ -333,16 +339,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
> u32 vid_mode = CMD_MODE;
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - vid_mode = SYNC_PULSE_MODE;
> -
> - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> vid_mode = BURST_MODE;
> + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + vid_mode = SYNC_PULSE_MODE;
> + else
> + vid_mode = SYNC_EVENT_MODE;
> }
>
> writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
> }
>
> +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> +{
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> +}
> +
> static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> {
> struct videomode *vm = &dsi->vm;
> @@ -480,6 +493,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
> writel(1, dsi->regs + DSI_START);
> }
>
> +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> +{
> + writel(0, dsi->regs + DSI_START);
> +}
> +
> +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> +{
> + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> +}
> +
> static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> {
> u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> @@ -538,6 +561,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32
> t)
> +{
> + mtk_dsi_irq_data_clear(dsi, irq_flag);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> + DRM_ERROR("failed to switch cmd mode\n");
> + return -ETIME;
> + } else {
> + return 0;
> + }
> +}
> +
> static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> {
> if (WARN_ON(dsi->refcount == 0))
> @@ -546,11 +582,6 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> if (--dsi->refcount != 0)
> return;
>
> - mtk_dsi_lane0_ulp_mode_enter(dsi);
> - mtk_dsi_clk_ulp_mode_enter(dsi);
> -
> - mtk_dsi_disable(dsi);
> -
> clk_disable_unprepare(dsi->engine_clk);
> clk_disable_unprepare(dsi->digital_clk);
>
> @@ -564,13 +595,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> if (dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
> ret = mtk_dsi_poweron(dsi);
> if (ret < 0) {
> DRM_ERROR("failed to power on dsi\n");
> @@ -578,21 +602,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> }
>
> mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);
Even though dsi does not directl
Re: [PATCH] auxdisplay: ht16k33: select required CONFIG_FB_CFB_* helpers
On Tue, 29 Nov 2016 21:04:30 +0100 Greg Kroah-Hartman wrote: > On Tue, Nov 29, 2016 at 08:55:50PM +0100, Arnd Bergmann wrote: > > On Tuesday, November 29, 2016 8:42:47 PM CET Greg Kroah-Hartman wrote: > > > On Fri, Nov 25, 2016 at 10:50:07AM +0100, Robin van der Gracht wrote: > > > > This selects the respective helpers required in addition to the one > > > > Arnd Bergmann pointer out earlier. > > > > > > > > Signed-off-by: Robin van der Gracht > > > > --- > > > > This is a responce to https://lkml.org/lkml/2016/11/25/66 > > > > This patch complements the changes Arnd submitted earlier. > > > > > > > > drivers/auxdisplay/Kconfig | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig > > > > index b8bbfc6..4ef4c5c 100644 > > > > --- a/drivers/auxdisplay/Kconfig > > > > +++ b/drivers/auxdisplay/Kconfig > > > > @@ -132,6 +132,9 @@ config HT16K33 > > > > tristate "Holtek Ht16K33 LED controller with keyscan" > > > > depends on FB && OF && I2C && INPUT > > > > select FB_SYS_FOPS > > > > + select FB_CFB_FILLRECT > > > > + select FB_CFB_COPYAREA > > > > + select FB_CFB_IMAGEBLIT > > > > select INPUT_MATRIXKMAP > > > > select FB_BACKLIGHT > > > > help > > > > > > What tree is this patch against? > > > > > > thanks, > > > > > > greg k-h > > > > > > > It's on top of my patch "auxdisplay: ht16k33: select CONFIG_FB_SYS_FOPS" > > from a few days ago. I guess Robin expected you to have picked that > > up, while you expected him to combine it with the new changes. > > > > Robin, I think it's easier if you send the combined patch and > > add "Reported-by: Arnd Bergmann ", as Greg has > > probably already droppped my earlier patch from his queue. > > Yes, it's not in my queue anymore. > > thanks, > > greg k-h I'll create a new patch. Regards, Robin
[PATCH] isofs: add KERN_CONT to printing of ER records
The ER records are printed without explicit log level presuming line
continuation until "\n". After the commit 4bcc595ccd8 (printk: reinstate
KERN_CONT for printing continuation lines), the ER records are printed
a character per line.
Adding KERN_CONT to appropriate printk statements restores the printout
behavior.
Signed-off-by: Mike Rapoport
---
fs/isofs/rock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c
index 98b3eb7..0ec1373 100644
--- a/fs/isofs/rock.c
+++ b/fs/isofs/rock.c
@@ -377,9 +377,9 @@ int get_rock_ridge_filename(struct iso_directory_record *de,
{
int p;
for (p = 0; p < rr->u.ER.len_id; p++)
- printk("%c", rr->u.ER.data[p]);
+ printk(KERN_CONT "%c",
rr->u.ER.data[p]);
}
- printk("\n");
+ printk(KERN_CONT "\n");
break;
case SIG('P', 'X'):
inode->i_mode = isonum_733(rr->u.PX.mode);
--
1.9.1
Re: [PATCH V3] leds: pca955x: Add ACPI support for pca955x
Hi Tin,
How this patch is different from the one already merged?
Best regards,
Jacek Anaszewski
On 11/30/2016 04:08 AM, Tin Huynh wrote:
This patch enables ACPI support for leds-pca955x driver.
Signed-off-by: Tin Huynh
---
drivers/leds/leds-pca955x.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
Change from V2:
-Correct coding conventions.
Change from V1:
-Remove CONFIG_ACPI.
diff --git a/drivers/leds/leds-pca955x.c b/drivers/leds/leds-pca955x.c
index 840401a..b168ebe 100644
--- a/drivers/leds/leds-pca955x.c
+++ b/drivers/leds/leds-pca955x.c
@@ -40,6 +40,7 @@
* bits the chip supports.
*/
+#include
#include
#include
#include
@@ -100,6 +101,15 @@ struct pca955x_chipdef {
};
MODULE_DEVICE_TABLE(i2c, pca955x_id);
+static const struct acpi_device_id pca955x_acpi_ids[] = {
+ { .id = "PCA9550", .driver_data = pca9550 },
+ { .id = "PCA9551", .driver_data = pca9551 },
+ { .id = "PCA9552", .driver_data = pca9552 },
+ { .id = "PCA9553", .driver_data = pca9553 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, pca955x_acpi_ids);
+
struct pca955x {
struct mutex lock;
struct pca955x_led *leds;
@@ -250,7 +260,16 @@ static int pca955x_probe(struct i2c_client *client,
struct led_platform_data *pdata;
int i, err;
- chip = &pca955x_chipdefs[id->driver_data];
+ if (id) {
+ chip = &pca955x_chipdefs[id->driver_data];
+ } else {
+ const struct acpi_device_id *acpi_id;
+
+ acpi_id = acpi_match_device(pca955x_acpi_ids, &client->dev);
+ if (!acpi_id)
+ return -ENODEV;
+ chip = &pca955x_chipdefs[acpi_id->driver_data];
+ }
adapter = to_i2c_adapter(client->dev.parent);
pdata = dev_get_platdata(&client->dev);
@@ -358,6 +377,7 @@ static int pca955x_remove(struct i2c_client *client)
static struct i2c_driver pca955x_driver = {
.driver = {
.name = "leds-pca955x",
+ .acpi_match_table = ACPI_PTR(pca955x_acpi_ids),
},
.probe = pca955x_probe,
.remove = pca955x_remove,
Re: [PATCH 17/39] mtd: nand: denali: support HW_ECC_FIXUP capability
On Wed, 30 Nov 2016 15:20:10 +0900
Masahiro Yamada wrote:
> Hi Boris,
>
>
> 2016-11-28 1:09 GMT+09:00 Boris Brezillon
> :
> &max_bitflips);
> >
> > Okay, so you currently have two ways of handling ECC errors. What if a
> > new revision introduces yet another way to do it?
> >
> > How about making denali_caps a structure where you have one (or several)
> > function pointers to implement operations differently depending on the
> > IP revision?
> >
> > struct denali_caps {
> > u32 feature_flags; /* If needed. */
> > bool (*handle_ecc)(...);
> > ...
> > };
> >
>
> I think a problem is the difference of function arguments:
>
> static bool denali_hw_ecc_fixup(struct denali_nand_info *denali,
> unsigned int *max_bitflips)
>
> vs
>
> static bool denali_sw_ecc_fixup(struct denali_nand_info *denali, u8 *buf,
> u32 irq_status, unsigned int *max_bitflips)
>
>
> I do not want to pass redundant arguments,
> which are used for one, but not used for the other.
>
We do that all the time when defining generic interfaces.
>
> We do not need to think about the situation that may not happen.
> If happens, we can refactor the code any time.
>
Well, as I said in my other reply, I still think it's better to plan
for this now, rather than having to change a lot things when we appear
to need this. But that's only my POV, and I don't care enough to fight.
Re: [PATCH 04/39] mtd: nand: denali: remove more unused struct members
On Wed, 30 Nov 2016 16:16:35 +0900
Masahiro Yamada wrote:
> Hi Boris,
>
>
> 2016-11-28 0:12 GMT+09:00 Boris Brezillon
> :
> > On Sun, 27 Nov 2016 03:05:50 +0900
> > Masahiro Yamada wrote:
> >
> > Please add a description here.
> >
> > Also, this commit tends to validate my fears: you should have wait for
> > the full rework/cleanup to be done before submitting the first round of
> > cleanups. Indeed, commit c4ae0977f57d ("mtd: nand: denali: remove unused
> > struct member denali_nand_info::idx") was removing one of these unused
> > fields, leaving 2 of them behind.
>
> Right.
> No difference except that
> denali->idx was initialized to zero(, but not referenced).
>
> I could squash the two patches.
That's not a big deal.
>
>
> > While I like when things I clearly separated in different commits, when
> > you push the logic too far, you end up with big series which are not
> > necessarily easier to review, and several commits that are achieving
> > the same goal...
>
>
> I must admit that I hurried up in posting the first round.
> But, please note I did not ask you to pick it up for v4.10-rc1.
> After all, it was your choice whether you picked it soon or
> waited until you saw the big picture.
> You could have postponed it until v4.11-rc1 if you had wanted.
That's true. But it was not clear from your cover letter that you
were posting this series just to get feedback and not necessarily to
get them applied.
>
> My idea was, I'd like to get feedback earlier
> (especially from Intel engineers).
>
> I fear that I do not reveal anything until I complete my work.
> If I am doing wrong in the early patches in my big series,
> I might end up with lots of effort to turn around.
>
> I dropped various Intel-specific things,
> for example commit c9e025843242 ("mtd: nand: denali: remove
> detect_partition_feature()")
> removed the whole function I do not understand.
> There was possibility that it might be locally used by Intel platforms.
>
> If I had gotten negative comments for removal, I'd have needed more efforts
> to not break any old functions.
>
> As a result, nobody was opposed to delete such things.
> So, I can confidently continue my work on cleaner and more *stable* base.
>
>
Okay, got it. So, I should not apply any patches from this series until
you've completed your rework (round2+3 posted).
I think I'll still apply patch 1 early, because it's not directly
related to the denali rework, and the fix looks good.
Regards,
Boris
Re: [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c
On Wed, Nov 30, 2016 at 08:16:02AM +0100, Michal Hocko wrote:
> On Tue 29-11-16 11:14:48, Paul E. McKenney wrote:
> > On Tue, Nov 29, 2016 at 05:21:19PM +, Sudeep Holla wrote:
> > > On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
> > > wrote:
> > > >
> > > > FYI, we noticed the following commit:
> > > >
> > > > commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent
> > > > __alloc_pages_nodemask() RCU CPU stall warnings")
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> > > > rcu/next
> > > >
> > > > in testcase: boot
> > > >
> > > > on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m
> > > > 1G
> > > >
> > > > caused below changes:
> > > >
> > > [...]
> > >
> > > > [8.953192] BUG: sleeping function called from invalid context at
> > > > mm/page_alloc.c:3746
> > > > [8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name:
> > > > swapper/0
> > >
> > > I am observing similar BUG/backtrace even on ARM64 platform.
> >
> > Does the (untested) patch below help?
> >
> > Thanx, Paul
> >
> >
> >
> > commit ccc0666e2049e5818c236e647cf20c552a7b053b
> > Author: Paul E. McKenney
> > Date: Tue Nov 29 11:06:05 2016 -0800
> >
> > rcu: Allow boot-time use of cond_resched_rcu_qs()
> >
> > The cond_resched_rcu_qs() macro is used to force RCU quiescent states
> > into
> > long-running in-kernel loops. However, some of these loops can execute
> > during early boot when interrupts are disabled, and during which time
> > it is therefore illegal to enter the scheduler. This commit therefore
> > makes cond_resched_rcu_qs() be a no-op during early boot.
> >
> > Signed-off-by: Paul E. McKenney
>
> This is not the problem with your "mm: Prevent __alloc_pages_nodemask()
> RCU CPU stall warnings", though. The main problem imho is that the
> allocator might be called from the atomic contexts (aka
> gfp_mask & ~__GFP_DIRECT_RECLAIM). Besides that I do not think that any
> variant of cond_resched inside the allocator hot path
> __alloc_pages_nodemask is just wrong. If anything such a scheduling/RCU
> point should be added to the slow path. But as I've said earlier we
> already have these points in that path so new ones shouldn't be really
> necessary.
>
> Could you drop this patch Paul, please?
Good point, dropped.
Boris's test results show that something else is needed, will review
his splats and see what else presents itself.
Thanx, Paul
[PATCH] cpufreq: dt: Add support for zx296718
Add the compatible string for supporting the generic cpufreq driver on
the ZTE's zx296718 SoC.
Signed-off-by: Baoyou Xie
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 7126762..c0a28e23b 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -81,6 +81,8 @@ static const struct of_device_id machines[] __initconst = {
{ .compatible = "xlnx,zynq-7000", },
+ { .compatible = "zte,zx296718", },
+
{ }
};
--
2.7.4
RE: [patch net / RFC] net: fec: increase frame size limitation to actually available buffer
From: Nikita Yushchenko Sent: Wednesday, November 30, 2016 2:36 PM >To: Andy Duan ; David S. Miller >; Troy Kisky ; >Andrew Lunn ; Eric Nelson ; Philippe >Reynes ; Johannes Berg ; >net...@vger.kernel.org >Cc: Chris Healy ; Fabio Estevam >; linux-kernel@vger.kernel.org >Subject: Re: [patch net / RFC] net: fec: increase frame size limitation to >actually available buffer > >> But I think it is not necessary since the driver don't support jumbo frame. > >Hardcoded 1522 raises two separate issues. > >(1) When DSA is in use, frames processed by FEC chip contain DSA tag and >thus can be larger than hardcoded limit of 1522. This issue is not >FEC-specific, >any driver that hardcodes maximum frame size to 1522 (many >do) will have this issue if used with DSA. > >Clean solution for this must take into account that difference between MTU >and max frame size is no longer known at compile time. Actually this is the >case even without DSA, due to VLANs: max frame size is (MTU + 18) without >VLANs, but (MTU + 22) with VLANs. However currently drivers tend to ignore >this and hardcode 22. With DSA, 22 is not enough, need to add switch- >specific tag size to that. > >Not yet sure how to handle this. DSA-specific API to find out tag size could >be >added, but generic solution should handle all cases of dynamic difference >between MTU and max frame size, not only DSA. > > >(2) There is some demand to use larger frames for optimization purposes. > >FEC register fields that limit frame size are 14-bit, thus allowing frames up >to >(4k-1). I'm about to prepare a larger patch: >- add ndo_change_mtu handler, allowing MTU up to (4k - overhead), >- set MAX_FL / TRUNC_FL based on configured MTU, >- if necessary, do buffer reallocation with larger buffers. > >Is this suitable for upstreaming? >Is there any policy related to handling larger frames? Of course, welcome to upstream the jumbo frame patches, but hope to also add the transmit jumbo frame, not only receive path, which is helpful for testing with two boards connection. And, some notes need you to care: - the maximum jumbo frame should consider the fifo size. Different chip has different fifo size. Like i.MX53 tx and rx share one fifo, i.mx6q/dl/sl have separate 4k fifo for tx and rx, i.mx6sx/i.mx7x have separate 8k fifo for tx and rx. - rx fifo watermark to generate pause frame in busy loading system to avoid fifo overrun. In general, little pause frames bring better performance, mass of pause frames cause worse performance. Regards, Andy
Re: [patch v2 1/2] mm, zone: track number of movable free pages
On 11/30/2016 01:16 AM, David Rientjes wrote:
An upcoming compaction change will need the number of movable free pages
per zone to determine if async compaction will become unnecessarily
expensive.
This patch introduces no functional change or increased memory footprint.
It simply tracks the number of free movable pages as a subset of the
total number of free pages. This is exported to userspace as part of a
new /proc/vmstat field.
Signed-off-by: David Rientjes
---
v2: do not track free pages per migratetype since page allocator stress
testing reveals this tracking can impact workloads and there is no
substantial benefit when thp is disabled. This occurs because
entire pageblocks can be converted to new migratetypes and requires
iteration of free_areas in the hotpaths for proper tracking.
Ah, right, forgot about the accuracy issue when focusing on the overhead
issue. Unfortunately I'm afraid the NR_FREE_MOVABLE_PAGES in this patch
will also drift uncontrollably over time. Stealing is one thing, and
also buddy merging can silently move free pages between migratetypes. It
already took some effort to make this accurate for MIGRATE_CMA and
MIGRATE_ISOLATE, which has some overhead and works only thanks to
additional constraints - CMA pageblocks don't ever get converted, and
for ISOLATE we don't put them on pcplists, perform pcplists draining
during isolation, and have extra code guarded by has_isolate_pageblock()
in buddy merging. None of this would be directly viable for
MIGRATE_MOVABLE I'm afraid.
include/linux/mmzone.h | 1 +
include/linux/vmstat.h | 2 ++
mm/page_alloc.c| 8 +++-
mm/vmstat.c| 1 +
4 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -138,6 +138,7 @@ enum zone_stat_item {
NUMA_OTHER, /* allocation from other node */
#endif
NR_FREE_CMA_PAGES,
+ NR_FREE_MOVABLE_PAGES,
NR_VM_ZONE_STAT_ITEMS };
enum node_stat_item {
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -347,6 +347,8 @@ static inline void __mod_zone_freepage_state(struct zone
*zone, int nr_pages,
__mod_zone_page_state(zone, NR_FREE_PAGES, nr_pages);
if (is_migrate_cma(migratetype))
__mod_zone_page_state(zone, NR_FREE_CMA_PAGES, nr_pages);
+ if (migratetype == MIGRATE_MOVABLE)
+ __mod_zone_page_state(zone, NR_FREE_MOVABLE_PAGES, nr_pages);
}
extern const char * const vmstat_text[];
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2197,6 +2197,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int
order,
spin_lock(&zone->lock);
for (i = 0; i < count; ++i) {
struct page *page = __rmqueue(zone, order, migratetype);
+ int mt;
+
if (unlikely(page == NULL))
break;
@@ -2217,9 +2219,13 @@ static int rmqueue_bulk(struct zone *zone, unsigned int
order,
else
list_add_tail(&page->lru, list);
list = &page->lru;
- if (is_migrate_cma(get_pcppage_migratetype(page)))
+ mt = get_pcppage_migratetype(page);
+ if (is_migrate_cma(mt))
__mod_zone_page_state(zone, NR_FREE_CMA_PAGES,
-(1 << order));
+ if (mt == MIGRATE_MOVABLE)
+ __mod_zone_page_state(zone, NR_FREE_MOVABLE_PAGES,
+ -(1 << order));
}
__mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));
spin_unlock(&zone->lock);
diff --git a/mm/vmstat.c b/mm/vmstat.c
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -945,6 +945,7 @@ const char * const vmstat_text[] = {
"numa_other",
#endif
"nr_free_cma",
+ "nr_free_movable",
/* Node-based counters */
"nr_inactive_anon",
[PATCH] arm64: dts: add zx296718's topcrm node
Enable topcrm clock node for zx296718, which is used for
CPU's frequency change.
Furthermore, this patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.
So it can be used by cpufreq-dt driver.
Signed-off-by: Baoyou Xie
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 48 +++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi
b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 6b239a3..f9eb37d 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
/ {
compatible = "zte,zx296718";
@@ -81,6 +82,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+ clocks = <&topcrm A53_GATE>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu@1 {
@@ -88,6 +91,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu2: cpu@2 {
@@ -95,6 +99,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu3: cpu@3 {
@@ -102,6 +107,43 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@10 {
+ opp-hz = /bits/ 64 <5>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <50>;
+ };
+ opp@11 {
+ opp-hz = /bits/ 64 <64800>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <50>;
+ };
+ opp@12 {
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = <882000>;
+ clock-latency-ns = <50>;
+ };
+ opp@13 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt = <892000>;
+ clock-latency-ns = <50>;
+ };
+ opp@14 {
+ opp-hz = /bits/ 64 <118800>;
+ opp-microvolt = <1009000>;
+ clock-latency-ns = <50>;
+ };
+ opp@15 {
+ opp-hz = /bits/ 64 <131200>;
+ opp-microvolt = <1052000>;
+ clock-latency-ns = <50>;
};
};
@@ -279,6 +321,12 @@
dma-requests = <32>;
};
+ topcrm: clock-controller@01461000 {
+ compatible = "zte,zx296718-topcrm";
+ reg = <0x01461000 0x1000>;
+ #clock-cells = <1>;
+ };
+
sysctrl: sysctrl@1463000 {
compatible = "zte,zx296718-sysctrl", "syscon";
reg = <0x1463000 0x1000>;
--
2.7.4
Another kernel OOPS still not fixed
Hello, There is another major kernel OOPS which is still not fixed over a year Bug 1279188 - bind-chroot causes kernel to crash on restart (mount with bind option): https://bugzilla.redhat.com/show_bug.cgi?id=1279188 Can you please fix it. Thnx. Ciao, Gerhard
[PATCH 08/11] ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
ACPICA commit cac6790954d4d752a083e610b8a22febcd07
This patch back ports Linux acpi_get_table_with_size() and
early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences.
The 2 APIs are used by Linux as table management APIs for long time, it
contains a hidden logic that during the early stage, the mapped tables
should be unmapped before the early stage ends.
During the early stage, tables are handled by the following sequence:
acpi_get_table_with_size();
parse the table
early_acpi_os_unmap_memory();
During the late stage, tables are handled by the following sequence:
acpi_get_table();
parse the table
Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the
late stage.
The reasoning of introducing acpi_get_table_with_size() is: ACPICA will
remember the early mapped pointer in acpi_get_table() and Linux isn't able to
prevent ACPICA from using the wrong early mapped pointer during the late
stage as there is no API provided from ACPICA to be an inverse of
acpi_get_table() to forget the early mapped pointer.
But how ACPICA can work with the early/late stage requirement? Inside of
ACPICA, tables are ensured to be remained in "INSTALLED" state during the
early stage, and they are carefully not transitioned to "VALIDATED" state
until the late stage. So the same logic is in fact implemented inside of
ACPICA in a different way. The gap is only that the feature is not provided
to the OSPMs in an accessible external API style.
It then is possible to fix the gap by providing an inverse of
acpi_get_table() from ACPICA, so that the two Linux sequences can be
combined:
acpi_get_table();
parse the table
acpi_put_table();
In order to work easier with the current Linux code, acpi_get_table() and
acpi_put_table() is implemented in a usage counting based style:
1. When the usage count of the table is increased from 0 to 1, table is
mapped and .Pointer is set with the mapping address (VALIDATED);
2. When the usage count of the table is decreased from 1 to 0, .Pointer
is unset and the mapping address is unmapped (INVALIDATED).
So that we can deploy the new APIs to Linux with minimal effort by just
invoking acpi_get_table() in acpi_get_table_with_size() and invoking
acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng.
Link: https://github.com/acpica/acpica/commit/cac67909
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/actables.h|6 ++
drivers/acpi/acpica/tbutils.c | 85
drivers/acpi/acpica/tbxface.c | 130 +++--
drivers/acpi/osl.c| 31 -
include/acpi/acpixf.h | 12 +++-
include/acpi/actbl.h |1 +
include/acpi/platform/aclinuxex.h |1 -
7 files changed, 212 insertions(+), 54 deletions(-)
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 7dd527f..94be8a8 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -166,6 +166,12 @@
acpi_status acpi_tb_parse_root_table(acpi_physical_address rsdp_address);
+acpi_status
+acpi_tb_get_table(struct acpi_table_desc *table_desc,
+ struct acpi_table_header **out_table);
+
+void acpi_tb_put_table(struct acpi_table_desc *table_desc);
+
/*
* tbxfload
*/
diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
index 51eb07c..86854e8 100644
--- a/drivers/acpi/acpica/tbutils.c
+++ b/drivers/acpi/acpica/tbutils.c
@@ -381,3 +381,88 @@ struct acpi_table_header *acpi_tb_copy_dsdt(u32
table_index)
acpi_os_unmap_memory(table, length);
return_ACPI_STATUS(AE_OK);
}
+
+/***
+ *
+ * FUNCTION:acpi_tb_get_table
+ *
+ * PARAMETERS: table_desc - Table descriptor
+ * out_table - Where the pointer to the table is
returned
+ *
+ * RETURN: Status and pointer to the requested table
+ *
+ * DESCRIPTION: Increase a reference to a table descriptor and return the
+ * validated table pointer.
+ * If the table descriptor is an entry of the root table list,
+ * this API must be invoked with ACPI_MTX_TABLES acquired.
+ *
+
**/
+
+acpi_status
+acpi_tb_get_table(struct acpi_table_desc *table_desc,
+ struct acpi_table_header **out_table)
+{
+ acpi_status status;
+
+ ACPI_FUNCTION_TRACE(acpi_tb_get_table);
+
+ if (table_desc->validation_count == 0) {
+
+ /* Table need to be "VALIDATED" */
+
+ status = acpi_tb_validate_table(table_desc);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+ }
+
+ table_desc->validation_count++;
+ if (table_desc->validation_count == 0) {
+ ACPI_ERROR((AE_INFO,
+
[PATCH 06/11] ACPICA: Tables: Add acpi_tb_unload_table()
ACPICA commit 80e24663b212daac0c32767fdbd8a46892292f1f
This patch introduces acpi_tb_unload_table() to eliminate redundant code from
acpi_ex_unload_table() and acpi_unload_parent_table().
No functional change. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/80e24663
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/actables.h |2 ++
drivers/acpi/acpica/exconfig.c | 35 +
drivers/acpi/acpica/tbdata.c | 48
drivers/acpi/acpica/tbxfload.c | 31 +-
4 files changed, 52 insertions(+), 64 deletions(-)
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 1850005..7dd527f 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -130,6 +130,8 @@
acpi_tb_install_and_load_table(acpi_physical_address address,
u8 flags, u8 override, u32 *table_index);
+acpi_status acpi_tb_unload_table(u32 table_index);
+
void acpi_tb_terminate(void);
acpi_status acpi_tb_delete_namespace_by_owner(u32 table_index);
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index 8b8d620..c32c782 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -499,7 +499,6 @@ acpi_status acpi_ex_unload_table(union acpi_operand_object
*ddb_handle)
acpi_status status = AE_OK;
union acpi_operand_object *table_desc = ddb_handle;
u32 table_index;
- struct acpi_table_header *table;
ACPI_FUNCTION_TRACE(ex_unload_table);
@@ -536,39 +535,7 @@ acpi_status acpi_ex_unload_table(union acpi_operand_object
*ddb_handle)
* strict order requirement against it.
*/
acpi_ex_exit_interpreter();
-
- /* Ensure the table is still loaded */
-
- if (!acpi_tb_is_table_loaded(table_index)) {
- status = AE_NOT_EXIST;
- goto lock_and_exit;
- }
-
- /* Invoke table handler if present */
-
- if (acpi_gbl_table_handler) {
- status = acpi_get_table_by_index(table_index, &table);
- if (ACPI_SUCCESS(status)) {
- (void)acpi_gbl_table_handler(ACPI_TABLE_EVENT_UNLOAD,
-table,
-
acpi_gbl_table_handler_context);
- }
- }
-
- /* Delete the portion of the namespace owned by this table */
-
- status = acpi_tb_delete_namespace_by_owner(table_index);
- if (ACPI_FAILURE(status)) {
- goto lock_and_exit;
- }
-
- (void)acpi_tb_release_owner_id(table_index);
- acpi_tb_set_table_loaded_flag(table_index, FALSE);
-
-lock_and_exit:
-
- /* Re-acquire the interpreter lock */
-
+ status = acpi_tb_unload_table(table_index);
acpi_ex_enter_interpreter();
/*
diff --git a/drivers/acpi/acpica/tbdata.c b/drivers/acpi/acpica/tbdata.c
index 4cbfa30..82b0b57 100644
--- a/drivers/acpi/acpica/tbdata.c
+++ b/drivers/acpi/acpica/tbdata.c
@@ -871,3 +871,51 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8
is_loaded)
(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
return_ACPI_STATUS(status);
}
+
+/***
+ *
+ * FUNCTION:acpi_tb_unload_table
+ *
+ * PARAMETERS: table_index - Table index
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: Unload an ACPI table
+ *
+
**/
+
+acpi_status acpi_tb_unload_table(u32 table_index)
+{
+ acpi_status status = AE_OK;
+ struct acpi_table_header *table;
+
+ ACPI_FUNCTION_TRACE(tb_unload_table);
+
+ /* Ensure the table is still loaded */
+
+ if (!acpi_tb_is_table_loaded(table_index)) {
+ return_ACPI_STATUS(AE_NOT_EXIST);
+ }
+
+ /* Invoke table handler if present */
+
+ if (acpi_gbl_table_handler) {
+ status = acpi_get_table_by_index(table_index, &table);
+ if (ACPI_SUCCESS(status)) {
+ (void)acpi_gbl_table_handler(ACPI_TABLE_EVENT_UNLOAD,
+table,
+
acpi_gbl_table_handler_context);
+ }
+ }
+
+ /* Delete the portion of the namespace owned by this table */
+
+ status = acpi_tb_delete_namespace_by_owner(table_index);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+
+ (void)acpi_tb_release_owner_id(table_index);
+ acpi_tb_set_table_loaded_flag(table_index, FALSE);
+ return_ACPI_STATUS(status);
+}
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 77de33b..82019c0 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/ac
[PATCH 04/11] ACPICA: Events: Fix acpi_ev_initialize_region() return value
ACPICA commit 543342ab7a676f4eb0c9f100d349388a84dff0e8
This patch changes acpi_ev_initialize_region(), stop returning AE_NOT_EXIST
from it so that, not only in acpi_ds_load2_end_op(), but all places invoking
this function won't emit exceptions. The exception can be seen in
acpi_ds_initialize_objects() when certain table loading mode is chosen.
This patch also removes useless acpi_ns_locked from acpi_ev_initialize_region()
as this function will always be invoked with interpreter lock held now, and
the lock granularity has been tuned to lock around _REG execution, thus it
is now handled by acpi_ex_exit_interpreter(). Lv Zheng.
Link: https://github.com/acpica/acpica/commit/543342ab
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acevents.h |4 +--
drivers/acpi/acpica/dsopcode.c |2 +-
drivers/acpi/acpica/dswload2.c | 13 +
drivers/acpi/acpica/evrgnini.c | 59
4 files changed, 27 insertions(+), 51 deletions(-)
diff --git a/drivers/acpi/acpica/acevents.h b/drivers/acpi/acpica/acevents.h
index 92fa47c..8a0049d 100644
--- a/drivers/acpi/acpica/acevents.h
+++ b/drivers/acpi/acpica/acevents.h
@@ -243,9 +243,7 @@ union acpi_operand_object
*acpi_ev_find_region_handler(acpi_adr_space_type
u32 function,
void *handler_context, void **region_context);
-acpi_status
-acpi_ev_initialize_region(union acpi_operand_object *region_obj,
- u8 acpi_ns_locked);
+acpi_status acpi_ev_initialize_region(union acpi_operand_object *region_obj);
/*
* evsci - SCI (System Control Interrupt) handling/dispatch
diff --git a/drivers/acpi/acpica/dsopcode.c b/drivers/acpi/acpica/dsopcode.c
index 4cc9d98..77fd7c8 100644
--- a/drivers/acpi/acpica/dsopcode.c
+++ b/drivers/acpi/acpica/dsopcode.c
@@ -84,7 +84,7 @@ acpi_status acpi_ds_initialize_region(acpi_handle obj_handle)
/* Namespace is NOT locked */
- status = acpi_ev_initialize_region(obj_desc, FALSE);
+ status = acpi_ev_initialize_region(obj_desc);
return (status);
}
diff --git a/drivers/acpi/acpica/dswload2.c b/drivers/acpi/acpica/dswload2.c
index e362182..651f35a 100644
--- a/drivers/acpi/acpica/dswload2.c
+++ b/drivers/acpi/acpica/dswload2.c
@@ -609,18 +609,7 @@ acpi_status acpi_ds_load2_end_op(struct acpi_walk_state
*walk_state)
status =
acpi_ev_initialize_region
- (acpi_ns_get_attached_object(node), FALSE);
-
- if (ACPI_FAILURE(status)) {
- /*
-* If AE_NOT_EXIST is returned, it is not fatal
-* because many regions get created before a
handler
-* is installed for said region.
-*/
- if (AE_NOT_EXIST == status) {
- status = AE_OK;
- }
- }
+ (acpi_ns_get_attached_object(node));
break;
case AML_NAME_OP:
diff --git a/drivers/acpi/acpica/evrgnini.c b/drivers/acpi/acpica/evrgnini.c
index 75ddd16..a909225 100644
--- a/drivers/acpi/acpica/evrgnini.c
+++ b/drivers/acpi/acpica/evrgnini.c
@@ -479,7 +479,6 @@ static u8 acpi_ev_is_pci_root_bridge(struct
acpi_namespace_node *node)
* FUNCTION:acpi_ev_initialize_region
*
* PARAMETERS: region_obj - Region we are initializing
- * acpi_ns_locked - Is namespace locked?
*
* RETURN: Status
*
@@ -497,19 +496,28 @@ static u8 acpi_ev_is_pci_root_bridge(struct
acpi_namespace_node *node)
* MUTEX: Interpreter should be unlocked, because we may run the _REG
* method for this region.
*
+ * NOTE:Possible incompliance:
+ * There is a behavior conflict in automatic _REG execution:
+ * 1. When the interpreter is evaluating a method, we can only
+ * automatically run _REG for the following case:
+ * operation_region (OPR1, 0x80, 0x110, 0x4)
+ * 2. When the interpreter is loading a table, we can also
+ * automatically run _REG for the following case:
+ * operation_region (OPR1, 0x80, 0x110, 0x4)
+ * Though this may not be compliant to the de-facto standard, the
+ * logic is kept in order not to trigger regressions. And keeping
+ * this logic should be taken care by the caller of this function.
+ *
**/
-acpi_status
-acpi_ev_initialize_region(union acpi_operand_object *region_obj,
- u8 acpi_ns_locked)
+acpi_status acpi_ev_initialize_region(union acpi_operand_object *region_obj)
{
uni
[PATCH 11/11] ACPICA: Update version to 20161117
From: Bob Moore ACPICA commit 0d5a056877c2e37e0bfce8d262cec339dc8d55fd Version 20161117. Link: https://github.com/acpica/acpica/commit/0d5a0568 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng --- include/acpi/acpixf.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index 33828dd..0d20c53 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -46,7 +46,7 @@ /* Current ACPICA subsystem version in MMDD format */ -#define ACPI_CA_VERSION 0x20160930 +#define ACPI_CA_VERSION 0x20161117 #include #include -- 1.7.10
[PATCH 05/11] ACPICA: Tables: Cleanup acpi_tb_install_and_load_table()
ACPICA commit 7fdac0289faa1c28b91413c8e394e87372aa69e6
acpi_tb_install_and_load_table() can invoke acpi_tb_load_table() to eliminate
redundant code.
No functional change. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/7fdac028
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/actables.h |3 +--
drivers/acpi/acpica/exconfig.c |7 +++
drivers/acpi/acpica/tbdata.c | 45 +---
drivers/acpi/acpica/tbxfload.c |7 +++
4 files changed, 12 insertions(+), 50 deletions(-)
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index e85953b..1850005 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -127,8 +127,7 @@
acpi_tb_load_table(u32 table_index, struct acpi_namespace_node *parent_node);
acpi_status
-acpi_tb_install_and_load_table(struct acpi_table_header *table,
- acpi_physical_address address,
+acpi_tb_install_and_load_table(acpi_physical_address address,
u8 flags, u8 override, u32 *table_index);
void acpi_tb_terminate(void);
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index 718428b..8b8d620 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -437,10 +437,9 @@
ACPI_INFO(("Dynamic OEM Table Load:"));
acpi_ex_exit_interpreter();
- status =
- acpi_tb_install_and_load_table(table, ACPI_PTR_TO_PHYSADDR(table),
- ACPI_TABLE_ORIGIN_INTERNAL_VIRTUAL,
- TRUE, &table_index);
+ status = acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
+
ACPI_TABLE_ORIGIN_INTERNAL_VIRTUAL,
+ TRUE, &table_index);
acpi_ex_enter_interpreter();
if (ACPI_FAILURE(status)) {
diff --git a/drivers/acpi/acpica/tbdata.c b/drivers/acpi/acpica/tbdata.c
index d9ca8c2..4cbfa30 100644
--- a/drivers/acpi/acpica/tbdata.c
+++ b/drivers/acpi/acpica/tbdata.c
@@ -832,9 +832,9 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8
is_loaded)
*
* FUNCTION:acpi_tb_install_and_load_table
*
- * PARAMETERS: table - Pointer to the table
- * address - Physical address of the table
+ * PARAMETERS: address - Physical address of the table
* flags - Allocation flags of the table
+ * override- Whether override should be performed
* table_index - Where table index is returned
*
* RETURN: Status
@@ -844,15 +844,13 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8
is_loaded)
**/
acpi_status
-acpi_tb_install_and_load_table(struct acpi_table_header *table,
- acpi_physical_address address,
+acpi_tb_install_and_load_table(acpi_physical_address address,
u8 flags, u8 override, u32 *table_index)
{
acpi_status status;
u32 i;
- acpi_owner_id owner_id;
- ACPI_FUNCTION_TRACE(acpi_load_table);
+ ACPI_FUNCTION_TRACE(tb_install_and_load_table);
(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
@@ -864,41 +862,8 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8
is_loaded)
goto unlock_and_exit;
}
- /*
-* Note: Now table is "INSTALLED", it must be validated before
-* using.
-*/
- status = acpi_tb_validate_table(&acpi_gbl_root_table_list.tables[i]);
- if (ACPI_FAILURE(status)) {
- goto unlock_and_exit;
- }
-
(void)acpi_ut_release_mutex(ACPI_MTX_TABLES);
- status = acpi_ns_load_table(i, acpi_gbl_root_node);
-
- /* Execute any module-level code that was found in the table */
-
- if (!acpi_gbl_parse_table_as_term_list
- && acpi_gbl_group_module_level_code) {
- acpi_ns_exec_module_code_list();
- }
-
- /*
-* Update GPEs for any new _Lxx/_Exx methods. Ignore errors. The host is
-* responsible for discovering any new wake GPEs by running _PRW methods
-* that may have been loaded by this table.
-*/
- status = acpi_tb_get_owner_id(i, &owner_id);
- if (ACPI_SUCCESS(status)) {
- acpi_ev_update_gpes(owner_id);
- }
-
- /* Invoke table handler if present */
-
- if (acpi_gbl_table_handler) {
- (void)acpi_gbl_table_handler(ACPI_TABLE_EVENT_LOAD, table,
-acpi_gbl_table_handler_context);
- }
+ status = acpi_tb_load_table(i, acpi_gbl_root_node);
(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
unlock_and_exit:
diff --git
[PATCH 01/11] ACPICA: Namespace: Add acpi_ns_handle_to_name()
ACPICA commit f9fe27a68a90c9d32dd3156241a5e788fb6956ea
This patch adds acpi_ns_handle_to_name() so that in the acpi_get_name():
1. Logics can be made simpler,
2. Lock held for acpi_ns_handle_to_name() can also be applied to
acpi_ns_handle_to_pathname().
The lock might be useless (see Link 1 below), but kept as acpi_get_name() is
an external API. Except the lock correction, this patch is a functional
no-op. BZ 1182, Lv Zheng.
Link: https://github.com/acpica/acpica/commit/f9fe27a6
Link: https://bugs.acpica.org/show_bug.cgi?id=1182 [# 1]
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/acnamesp.h |3 +++
drivers/acpi/acpica/nsnames.c | 45
drivers/acpi/acpica/nsxfname.c | 43 ++
3 files changed, 59 insertions(+), 32 deletions(-)
diff --git a/drivers/acpi/acpica/acnamesp.h b/drivers/acpi/acpica/acnamesp.h
index bb7fca1..7affdcd 100644
--- a/drivers/acpi/acpica/acnamesp.h
+++ b/drivers/acpi/acpica/acnamesp.h
@@ -292,6 +292,9 @@ char *acpi_ns_get_normalized_pathname(struct
acpi_namespace_node *node,
char *acpi_ns_name_of_current_scope(struct acpi_walk_state *walk_state);
acpi_status
+acpi_ns_handle_to_name(acpi_handle target_handle, struct acpi_buffer *buffer);
+
+acpi_status
acpi_ns_handle_to_pathname(acpi_handle target_handle,
struct acpi_buffer *buffer, u8 no_trailing);
diff --git a/drivers/acpi/acpica/nsnames.c b/drivers/acpi/acpica/nsnames.c
index f03dd41..94d5d33 100644
--- a/drivers/acpi/acpica/nsnames.c
+++ b/drivers/acpi/acpica/nsnames.c
@@ -97,6 +97,51 @@ acpi_size acpi_ns_get_pathname_length(struct
acpi_namespace_node *node)
/***
*
+ * FUNCTION:acpi_ns_handle_to_name
+ *
+ * PARAMETERS: target_handle - Handle of named object whose name is
+ *to be found
+ * buffer - Where the name is returned
+ *
+ * RETURN: Status, Buffer is filled with name if status is AE_OK
+ *
+ * DESCRIPTION: Build and return a full namespace name
+ *
+
**/
+
+acpi_status
+acpi_ns_handle_to_name(acpi_handle target_handle, struct acpi_buffer *buffer)
+{
+ acpi_status status;
+ struct acpi_namespace_node *node;
+ const char *node_name;
+
+ ACPI_FUNCTION_TRACE_PTR(ns_handle_to_name, target_handle);
+
+ node = acpi_ns_validate_handle(target_handle);
+ if (!node) {
+ return_ACPI_STATUS(AE_BAD_PARAMETER);
+ }
+
+ /* Validate/Allocate/Clear caller buffer */
+
+ status = acpi_ut_initialize_buffer(buffer, ACPI_PATH_SEGMENT_LENGTH);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+
+ /* Just copy the ACPI name from the Node and zero terminate it */
+
+ node_name = acpi_ut_get_node_name(node);
+ ACPI_MOVE_NAME(buffer->pointer, node_name);
+ ((char *)buffer->pointer)[ACPI_NAME_SIZE] = 0;
+
+ ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "%4.4s\n", (char *)buffer->pointer));
+ return_ACPI_STATUS(AE_OK);
+}
+
+/***
+ *
* FUNCTION:acpi_ns_handle_to_pathname
*
* PARAMETERS: target_handle - Handle of named object whose name is
diff --git a/drivers/acpi/acpica/nsxfname.c b/drivers/acpi/acpica/nsxfname.c
index 76a1bd4..e525cbe 100644
--- a/drivers/acpi/acpica/nsxfname.c
+++ b/drivers/acpi/acpica/nsxfname.c
@@ -158,8 +158,6 @@ static char *acpi_ns_copy_device_id(struct
acpi_pnp_device_id *dest,
acpi_get_name(acpi_handle handle, u32 name_type, struct acpi_buffer *buffer)
{
acpi_status status;
- struct acpi_namespace_node *node;
- const char *node_name;
/* Parameter validation */
@@ -172,18 +170,6 @@ static char *acpi_ns_copy_device_id(struct
acpi_pnp_device_id *dest,
return (status);
}
- if (name_type == ACPI_FULL_PATHNAME ||
- name_type == ACPI_FULL_PATHNAME_NO_TRAILING) {
-
- /* Get the full pathname (From the namespace root) */
-
- status = acpi_ns_handle_to_pathname(handle, buffer,
- name_type ==
- ACPI_FULL_PATHNAME ? FALSE :
- TRUE);
- return (status);
- }
-
/*
* Wants the single segment ACPI name.
* Validate handle and convert to a namespace Node
@@ -193,27 +179,20 @@ static char *acpi_ns_copy_device_id(struct
acpi_pnp_device_id *dest,
return (status);
}
- node = acpi_ns_validate_handle(handle);
- if (!node) {
- status = AE_BAD_PARAMETER;
- goto unlock_and_exi
Still OOM problems with 4.9er kernels
Hello, I'm having out of memory situations with my "low memory" VMs in KVM under Fedora (Kernel 4.7, 4.8 and also before). They started to get more and more sensitive to OOM. I recently found the following info: https://marius.bloggt-in-braunschweig.de/2016/11/17/linuxkernel-4-74-8-und-der-oom-killer/ https://www.spinics.net/lists/linux-mm/msg113661.html Therefore I tried the latest Fedora kernels: 4.9.0-0.rc6.git2.1.fc26.x86_64 But OOM situation is still very easy to reproduce: 1.) VM with 128-384MB under Fedora 25 2.) Having some processes run without any load (e.g. Apache) 3.) run an update with: dnf clean all; dnf update 4.) dnf python process get's killed Please make the VM system working again in Kernel 4.9 and to use swap again correctly. Thnx. Ciao, Gerhard
Re: Still OOM problems with 4.9er kernels
Hello, See also: Bug 1314697 - Kernel 4.4.3-300.fc23.x86_64 is not stable inside a KVM VM https://bugzilla.redhat.com/show_bug.cgi?id=1314697 Ciao, Gerhard On 30.11.2016 08:10, Gerhard Wiesinger wrote: Hello, I'm having out of memory situations with my "low memory" VMs in KVM under Fedora (Kernel 4.7, 4.8 and also before). They started to get more and more sensitive to OOM. I recently found the following info: https://marius.bloggt-in-braunschweig.de/2016/11/17/linuxkernel-4-74-8-und-der-oom-killer/ https://www.spinics.net/lists/linux-mm/msg113661.html Therefore I tried the latest Fedora kernels: 4.9.0-0.rc6.git2.1.fc26.x86_64 But OOM situation is still very easy to reproduce: 1.) VM with 128-384MB under Fedora 25 2.) Having some processes run without any load (e.g. Apache) 3.) run an update with: dnf clean all; dnf update 4.) dnf python process get's killed Please make the VM system working again in Kernel 4.9 and to use swap again correctly. Thnx. Ciao, Gerhard
[PATCH] printk: Fix spinlock deadlock in printk reenty
From: Jinling Ke
when Oops in printk, printk will call zap_locks() to reinitialize
spinlock to prevent deadlock. In arm, arm64, x86 or other
architecture smp cpu, race condition will occur in printk spinlock
logbuf_lock and then it will result other cpu that is waiting printk
spinlock in deadlock(in function raw_spin_lock). Because the cpus
deadlock, you can see the error printk log:
"SMP: failed to stop secondary CPUs"
In arm, arm64, x86 or other architecture, spinlock variable
is divided into 2 parts, for example they are 'owner' and 'next' in arm.
When get a spinlock, the 'next' part will add 1 and wait 'next' being
equal to 'owner'. However, at this moment, the 'next' part is local
variable, but 'owner' part value is get from global variable logbuf_lock.
However,raw_spin_lock_init(&logbuf_lock) will set 'owner' part and
'next' part to zero, the result is that cpu deadlock in function
raw_spin_lock( while loop in function arch_spin_lock ).
struct of arm spinlock
union {
u32 slock;
struct __raw_tickets {
u16 owner;
u16 next;
} tickets;
};
} arch_spinlock_t;
static inline void arch_spin_lock(arch_spinlock_t *lock)
{...
<--- At the moment, other cpu call
zap_locks()->spin_lock_init(),
<--- set the 'owner' part to zero, but lockval.tickets.next is a
<--- local variable
while (lockval.tickets.next != lockval.tickets.owner) {
lockval.tickets.owner =
ACCESS_ONCE(lock->tickets.owner);
}
...
}
The solution is that In function zap_locks(), replace
raw_spin_lock_init(&logbuf_lock) with raw_spin_unlock(&logbuf_lock),
to let spin_lock stay in unlocked.
Signed-off-by: Jinling Ke
---
kernel/printk/printk.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index f7a55e9..05b1886 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1603,7 +1603,7 @@ static void zap_locks(void)
debug_locks_off();
/* If a crash is occurring, make sure we can't deadlock */
- raw_spin_lock_init(&logbuf_lock);
+ raw_spin_unlock(&logbuf_lock);
/* And make sure that we print immediately */
sema_init(&console_sem, 1);
}
--
1.7.9.5
[PATCH 10/11] ACPICA: Utilities: Add new decode function for parser values
From: Bob Moore
ACPICA commit 198fde8a061ac77357bcf1752e3c988fbe59f128
Implements a decode function for the ARGP_* parser info values
for all AML opcodes.
Link: https://github.com/acpica/acpica/commit/198fde8a
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acutils.h |2 ++
drivers/acpi/acpica/amlcode.h |1 +
drivers/acpi/acpica/utdecode.c | 49
3 files changed, 52 insertions(+)
diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h
index 0a1b53c..845afb1 100644
--- a/drivers/acpi/acpica/acutils.h
+++ b/drivers/acpi/acpica/acutils.h
@@ -232,6 +232,8 @@ struct acpi_pkg_info {
const char *acpi_ut_get_event_name(u32 event_id);
+const char *acpi_ut_get_argument_type_name(u32 arg_type);
+
char acpi_ut_hex_to_ascii_char(u64 integer, u32 position);
acpi_status acpi_ut_ascii_to_hex_byte(char *two_ascii_chars, u8 *return_byte);
diff --git a/drivers/acpi/acpica/amlcode.h b/drivers/acpi/acpica/amlcode.h
index 04fbd88..8a0f959 100644
--- a/drivers/acpi/acpica/amlcode.h
+++ b/drivers/acpi/acpica/amlcode.h
@@ -240,6 +240,7 @@
#define ARGP_QWORDDATA 0x11
#define ARGP_SIMPLENAME 0x12 /* name_string | local_term |
arg_term */
#define ARGP_NAME_OR_REF0x13 /* For object_type only */
+#define ARGP_MAX0x13
/*
* Resolved argument types for the AML Interpreter
diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
index 15728ad..b3d8421 100644
--- a/drivers/acpi/acpica/utdecode.c
+++ b/drivers/acpi/acpica/utdecode.c
@@ -44,6 +44,7 @@
#include
#include "accommon.h"
#include "acnamesp.h"
+#include "amlcode.h"
#define _COMPONENT ACPI_UTILITIES
ACPI_MODULE_NAME("utdecode")
@@ -532,6 +533,54 @@ const char *acpi_ut_get_notify_name(u32 notify_value,
acpi_object_type type)
return ("Hardware-Specific");
}
+
+/***
+ *
+ * FUNCTION:acpi_ut_get_argument_type_name
+ *
+ * PARAMETERS: arg_type- an ARGP_* parser argument type
+ *
+ * RETURN: Decoded ARGP_* type
+ *
+ * DESCRIPTION: Decode an ARGP_* parser type, as defined in the amlcode.h file,
+ * and used in the acopcode.h file. For example, ARGP_TERMARG.
+ * Used for debug only.
+ *
+
**/
+
+static const char *acpi_gbl_argument_type[20] = {
+ /* 00 */ "Unknown ARGP",
+ /* 01 */ "ByteData",
+ /* 02 */ "ByteList",
+ /* 03 */ "CharList",
+ /* 04 */ "DataObject",
+ /* 05 */ "DataObjectList",
+ /* 06 */ "DWordData",
+ /* 07 */ "FieldList",
+ /* 08 */ "Name",
+ /* 09 */ "NameString",
+ /* 0A */ "ObjectList",
+ /* 0B */ "PackageLength",
+ /* 0C */ "SuperName",
+ /* 0D */ "Target",
+ /* 0E */ "TermArg",
+ /* 0F */ "TermList",
+ /* 10 */ "WordData",
+ /* 11 */ "QWordData",
+ /* 12 */ "SimpleName",
+ /* 13 */ "NameOrRef"
+};
+
+const char *acpi_ut_get_argument_type_name(u32 arg_type)
+{
+
+ if (arg_type > ARGP_MAX) {
+ return ("Unknown ARGP");
+ }
+
+ return (acpi_gbl_argument_type[arg_type]);
+}
+
#endif
/***
--
1.7.10
Re: [PATCH 21/39] mtd: nand: denali: support 64bit capable DMA engine
On Wed, 30 Nov 2016 16:11:53 +0900 Masahiro Yamada wrote: > Hi Boris, > > 2016-11-28 1:16 GMT+09:00 Boris Brezillon > : > > > > If you follow my suggestions of definition function pointers, you'll > > just have to add a function pointer to the denali_caps struct: > > > > void (*setup_dma)(struct denali_nand_info *denali, int op); > > > > > This is possible because both 32B and 64B variants have > the same function prototype. > > > However, I am not keen on doing so for ecc_handle(), > so, at this moment, I am not keen on doing so only for setup_dma() either. > > If I see more cases that fit in callback handler approach, > I will think about switching to it with consistency. > Pretty much all the flags you define in this series could be turned into function pointers. I still think the function pointers approach is more future-proof, but I won't fight on that, so do as you wish.
[PATCH 02/11] ACPICA: Back port of "ACPICA: Dispatcher: Tune interpreter lock around AcpiEvInitializeRegion()"
ACPICA commit bc481e758e54f7644fd0b657119ca7763d8b6a9c
This is a back port result of the following commit:
Commit: 8633db6b027952449e155a316f4ae3a530bbe18f
Subject: ACPICA: Dispatcher: Fix interpreter locking around
acpi_ev_initialize_region()
Link: https://github.com/acpica/acpica/commit/bc481e75
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/dsinit.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/dsinit.c b/drivers/acpi/acpica/dsinit.c
index 54d48b9..5de3f10 100644
--- a/drivers/acpi/acpica/dsinit.c
+++ b/drivers/acpi/acpica/dsinit.c
@@ -221,8 +221,8 @@
*/
status =
acpi_ns_walk_namespace(ACPI_TYPE_ANY, start_node, ACPI_UINT32_MAX,
- 0, acpi_ds_init_one_object, NULL, &info,
- NULL);
+ ACPI_NS_WALK_NO_UNLOCK,
+ acpi_ds_init_one_object, NULL, &info, NULL);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status, "During WalkNamespace"));
}
--
1.7.10
[PATCH 09/11] ACPICA: Tables: Allow FADT to be customized with virtual address
ACPICA commit d98de9ca14891130efc5dcdc871b97eb27b4b0f5
FADT parsing code requires FADT to be installed as
ACPI_TABLE_ORIGIN_INTERNAL_PHYSICAL, using new
acpi_tb_get_table()/acpi_tb_put_table(), other address types can also be
allowed,
thus facilitates FADT customization with virtual address. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/d98de9ca
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/tbfadt.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 5fb838e..81473a4 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -311,6 +311,8 @@ void acpi_tb_parse_fadt(void)
{
u32 length;
struct acpi_table_header *table;
+ struct acpi_table_desc *fadt_desc;
+ acpi_status status;
/*
* The FADT has multiple versions with different lengths,
@@ -319,14 +321,12 @@ void acpi_tb_parse_fadt(void)
* Get a local copy of the FADT and convert it to a common format
* Map entire FADT, assumed to be smaller than one page.
*/
- length = acpi_gbl_root_table_list.tables[acpi_gbl_fadt_index].length;
-
- table =
- acpi_os_map_memory(acpi_gbl_root_table_list.
- tables[acpi_gbl_fadt_index].address, length);
- if (!table) {
+ fadt_desc = &acpi_gbl_root_table_list.tables[acpi_gbl_fadt_index];
+ status = acpi_tb_get_table(fadt_desc, &table);
+ if (ACPI_FAILURE(status)) {
return;
}
+ length = fadt_desc->length;
/*
* Validate the FADT checksum before we copy the table. Ignore
@@ -340,7 +340,7 @@ void acpi_tb_parse_fadt(void)
/* All done with the real FADT, unmap it */
- acpi_os_unmap_memory(table, length);
+ acpi_tb_put_table(fadt_desc);
/* Obtain the DSDT and FACS tables via their addresses within the FADT
*/
--
1.7.10
[PATCH 07/11] ACPICA: Tables: Add an error message complaining driver bugs
ACPICA commit 68af3c3aa238dd8040e846ac6b4827a016434d8d
During early OS boot stage, drivers that have mapped system memory should
unmap it during the same stage. Linux kernel has an error message
indicating the unbalanced early memory mappings.
This patch back ports such error message into ACPICA for the early table
mappings, so that ACPICA development environment is also aware of this OS
specific requirement and thus is able to ensure the consistent quality
locally. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/68af3c3a
Signed-off-by: Lv Zheng
Signed-off-by: Bob Moore
---
drivers/acpi/acpica/tbxface.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c
index 4ab6b9c..d5adb7a 100644
--- a/drivers/acpi/acpica/tbxface.c
+++ b/drivers/acpi/acpica/tbxface.c
@@ -167,6 +167,7 @@ acpi_status acpi_allocate_root_table(u32
initial_table_count)
acpi_status ACPI_INIT_FUNCTION acpi_reallocate_root_table(void)
{
acpi_status status;
+ u32 i;
ACPI_FUNCTION_TRACE(acpi_reallocate_root_table);
@@ -178,6 +179,21 @@ acpi_status ACPI_INIT_FUNCTION
acpi_reallocate_root_table(void)
return_ACPI_STATUS(AE_SUPPORT);
}
+ /*
+* Ensure OS early boot logic, which is required by some hosts. If the
+* table state is reported to be wrong, developers should fix the
+* issue by invoking acpi_put_table() for the reported table during the
+* early stage.
+*/
+ for (i = 0; i < acpi_gbl_root_table_list.current_table_count; ++i) {
+ if (acpi_gbl_root_table_list.tables[i].pointer) {
+ ACPI_ERROR((AE_INFO,
+ "Table [%4.4s] is not invalidated during
early boot stage",
+ acpi_gbl_root_table_list.tables[i].
+ signature.ascii));
+ }
+ }
+
acpi_gbl_root_table_list.flags |= ACPI_ROOT_ALLOW_RESIZE;
status = acpi_tb_resize_root_table_list();
--
1.7.10
[PATCH 00/11] ACPICA: 20161117 Release
The 20161117 ACPICA kernel-resident subsystem updates are linuxized based on the linux-pm/linux-next branch. The patchset has passed the following build/boot tests. Build tests are performed as follows: 1. i386 + allyes 2. i386 + allno 3. i386 + default + ACPI_DEBUGGER=y 4. i386 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y 5. i386 + default + ACPI_DEBUG=n + ACPI=y 6. i386 + default + ACPI=n 7. x86_64 + allyes 8. x86_64 + allno 9. x86_64 + default + ACPI_DEBUGGER=y 10.x86_64 + default + ACPI_DEBUGGER=n + ACPI_DEBUG=y 11.x86_64 + default + ACPI_DEBUG=n + ACPI=y 12.x86_64 + default + ACPI=n Boot tests are performed as follows: 1. i386 + default + ACPI_DEBUGGER=y 2. x86_64 + default + ACPI_DEBUGGER=y Where: 1. i386: machine named as "Dell Inspiron Mini 1010" 2. x86_64: machine named as "Microsoft Surface Pro 3" 3. default: kernel configuration with following items enabled: All hardware drivers related to the machines of i386/x86_64 All "drivers/acpi" configurations All "drivers/platform" drivers All other drivers that link the APIs provided by ACPICA subsystem The divergences checking result: Before applying (20160930 Release): 508 lines After applying (20161117 Release): 467 lines Bob Moore (3): ACPICA: Fix for implicit result conversion for the To functions ACPICA: Utilities: Add new decode function for parser values ACPICA: Update version to 20161117 Lv Zheng (8): ACPICA: Namespace: Add acpi_ns_handle_to_name() ACPICA: Back port of "ACPICA: Dispatcher: Tune interpreter lock around AcpiEvInitializeRegion()" ACPICA: Events: Fix acpi_ev_initialize_region() return value ACPICA: Tables: Cleanup acpi_tb_install_and_load_table() ACPICA: Tables: Add acpi_tb_unload_table() ACPICA: Tables: Add an error message complaining driver bugs ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel ACPICA: Tables: Allow FADT to be customized with virtual address drivers/acpi/acpica/acevents.h|4 +- drivers/acpi/acpica/acnamesp.h|3 + drivers/acpi/acpica/acopcode.h| 14 ++-- drivers/acpi/acpica/actables.h| 11 ++- drivers/acpi/acpica/acutils.h |2 + drivers/acpi/acpica/amlcode.h | 21 +- drivers/acpi/acpica/dsinit.c |4 +- drivers/acpi/acpica/dsopcode.c|2 +- drivers/acpi/acpica/dswload2.c| 13 +--- drivers/acpi/acpica/evrgnini.c| 59 ++- drivers/acpi/acpica/exconfig.c| 42 +-- drivers/acpi/acpica/exconvrt.c|1 - drivers/acpi/acpica/exresop.c |1 - drivers/acpi/acpica/nsnames.c | 45 drivers/acpi/acpica/nsxfname.c| 43 +++ drivers/acpi/acpica/tbdata.c | 81 +++- drivers/acpi/acpica/tbfadt.c | 14 ++-- drivers/acpi/acpica/tbutils.c | 85 + drivers/acpi/acpica/tbxface.c | 146 + drivers/acpi/acpica/tbxfload.c| 38 +- drivers/acpi/acpica/utdecode.c| 49 + drivers/acpi/osl.c| 31 +++- include/acpi/acpixf.h | 14 +++- include/acpi/actbl.h |1 + include/acpi/platform/aclinuxex.h |1 - 25 files changed, 458 insertions(+), 267 deletions(-) -- 1.7.10
Re: [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c
On Tue 29-11-16 11:14:48, Paul E. McKenney wrote:
> On Tue, Nov 29, 2016 at 05:21:19PM +, Sudeep Holla wrote:
> > On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
> > wrote:
> > >
> > > FYI, we noticed the following commit:
> > >
> > > commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent
> > > __alloc_pages_nodemask() RCU CPU stall warnings")
> > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> > > rcu/next
> > >
> > > in testcase: boot
> > >
> > > on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 1G
> > >
> > > caused below changes:
> > >
> > [...]
> >
> > > [8.953192] BUG: sleeping function called from invalid context at
> > > mm/page_alloc.c:3746
> > > [8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
> >
> > I am observing similar BUG/backtrace even on ARM64 platform.
>
> Does the (untested) patch below help?
>
> Thanx, Paul
>
>
>
> commit ccc0666e2049e5818c236e647cf20c552a7b053b
> Author: Paul E. McKenney
> Date: Tue Nov 29 11:06:05 2016 -0800
>
> rcu: Allow boot-time use of cond_resched_rcu_qs()
>
> The cond_resched_rcu_qs() macro is used to force RCU quiescent states into
> long-running in-kernel loops. However, some of these loops can execute
> during early boot when interrupts are disabled, and during which time
> it is therefore illegal to enter the scheduler. This commit therefore
> makes cond_resched_rcu_qs() be a no-op during early boot.
>
> Signed-off-by: Paul E. McKenney
This is not the problem with your "mm: Prevent __alloc_pages_nodemask()
RCU CPU stall warnings", though. The main problem imho is that the
allocator might be called from the atomic contexts (aka
gfp_mask & ~__GFP_DIRECT_RECLAIM). Besides that I do not think that any
variant of cond_resched inside the allocator hot path
__alloc_pages_nodemask is just wrong. If anything such a scheduling/RCU
point should be added to the slow path. But as I've said earlier we
already have these points in that path so new ones shouldn't be really
necessary.
Could you drop this patch Paul, please?
--
Michal Hocko
SUSE Labs
Re: [PATCH 04/39] mtd: nand: denali: remove more unused struct members
Hi Boris,
2016-11-28 0:12 GMT+09:00 Boris Brezillon :
> On Sun, 27 Nov 2016 03:05:50 +0900
> Masahiro Yamada wrote:
>
> Please add a description here.
>
> Also, this commit tends to validate my fears: you should have wait for
> the full rework/cleanup to be done before submitting the first round of
> cleanups. Indeed, commit c4ae0977f57d ("mtd: nand: denali: remove unused
> struct member denali_nand_info::idx") was removing one of these unused
> fields, leaving 2 of them behind.
Right.
No difference except that
denali->idx was initialized to zero(, but not referenced).
I could squash the two patches.
> While I like when things I clearly separated in different commits, when
> you push the logic too far, you end up with big series which are not
> necessarily easier to review, and several commits that are achieving
> the same goal...
I must admit that I hurried up in posting the first round.
But, please note I did not ask you to pick it up for v4.10-rc1.
After all, it was your choice whether you picked it soon or
waited until you saw the big picture.
You could have postponed it until v4.11-rc1 if you had wanted.
My idea was, I'd like to get feedback earlier
(especially from Intel engineers).
I fear that I do not reveal anything until I complete my work.
If I am doing wrong in the early patches in my big series,
I might end up with lots of effort to turn around.
I dropped various Intel-specific things,
for example commit c9e025843242 ("mtd: nand: denali: remove
detect_partition_feature()")
removed the whole function I do not understand.
There was possibility that it might be locally used by Intel platforms.
If I had gotten negative comments for removal, I'd have needed more efforts
to not break any old functions.
As a result, nobody was opposed to delete such things.
So, I can confidently continue my work on cleaner and more *stable* base.
--
Best Regards
Masahiro Yamada
Re: [PATCH 21/39] mtd: nand: denali: support 64bit capable DMA engine
Hi Boris, 2016-11-28 1:16 GMT+09:00 Boris Brezillon : > > If you follow my suggestions of definition function pointers, you'll > just have to add a function pointer to the denali_caps struct: > > void (*setup_dma)(struct denali_nand_info *denali, int op); > This is possible because both 32B and 64B variants have the same function prototype. However, I am not keen on doing so for ecc_handle(), so, at this moment, I am not keen on doing so only for setup_dma() either. If I see more cases that fit in callback handler approach, I will think about switching to it with consistency. -- Best Regards Masahiro Yamada
[PATCH] lib/idr: trivial: Fix typo in file header
Signed-off-by: Cao jin --- lib/idr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/idr.c b/lib/idr.c index 6098336df267..69fa487dbfda 100644 --- a/lib/idr.c +++ b/lib/idr.c @@ -14,7 +14,7 @@ * by the id to obtain the pointer. The bitmap makes allocating * a new id quick. * - * You call it to allocate an id (an int) an associate with that id a + * You call it to allocate an id (an int) and associate with that id a * pointer or what ever, we treat it as a (void *). You can pass this * id to a user for him to pass back at a later time. You then pass * that id to this code and it returns your pointer. -- 2.1.0
[PATCH] vfio: Fix handling of error returned by 'vfio_group_get_from_dev()'
'vfio_group_get_from_dev()' seems to return only NULL on error, not an error
pointer.
Fixes: 2169037dc322 ("vfio iommu: Added pin and unpin callback functions to
vfio_iommu_driver_ops")
Fixes: c086de818dd8 ("vfio iommu: Add blocking notifier to notify DMA_UNMAP")
Signed-off-by: Christophe JAILLET
---
This could be split in 2 patches in order to have only one Fixes tag in
each
---
drivers/vfio/vfio.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 0aac3ca54a53..7b39313abf0d 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1933,8 +1933,8 @@ int vfio_pin_pages(struct device *dev, unsigned long
*user_pfn, int npage,
return -E2BIG;
group = vfio_group_get_from_dev(dev);
- if (IS_ERR(group))
- return PTR_ERR(group);
+ if (!group)
+ return -ENODEV;
ret = vfio_group_add_container_user(group);
if (ret)
@@ -1982,8 +1982,8 @@ int vfio_unpin_pages(struct device *dev, unsigned long
*user_pfn, int npage)
return -E2BIG;
group = vfio_group_get_from_dev(dev);
- if (IS_ERR(group))
- return PTR_ERR(group);
+ if (!group)
+ return -ENODEV;
ret = vfio_group_add_container_user(group);
if (ret)
@@ -2019,8 +2019,8 @@ int vfio_register_notifier(struct device *dev, struct
notifier_block *nb)
return -EINVAL;
group = vfio_group_get_from_dev(dev);
- if (IS_ERR(group))
- return PTR_ERR(group);
+ if (!group)
+ return -ENODEV;
ret = vfio_group_add_container_user(group);
if (ret)
@@ -2055,8 +2055,8 @@ int vfio_unregister_notifier(struct device *dev, struct
notifier_block *nb)
return -EINVAL;
group = vfio_group_get_from_dev(dev);
- if (IS_ERR(group))
- return PTR_ERR(group);
+ if (!group)
+ return -ENODEV;
ret = vfio_group_add_container_user(group);
if (ret)
--
2.9.3
Re: next: Commit 'mm: Prevent __alloc_pages_nodemask() RCU CPU stall ...' causing hang on sparc32 qemu
On Tue, Nov 29, 2016 at 08:32:51PM -0800, Guenter Roeck wrote:
> On 11/29/2016 05:28 PM, Paul E. McKenney wrote:
> >On Tue, Nov 29, 2016 at 01:23:08PM -0800, Guenter Roeck wrote:
> >>Hi Paul,
> >>
> >>most of my qemu tests for sparc32 targets started to fail in next-20161129.
> >>The problem is only seen in SMP builds; non-SMP builds are fine.
> >>Bisect points to commit 2d66cccd73436 ("mm: Prevent __alloc_pages_nodemask()
> >>RCU CPU stall warnings"); reverting that commit fixes the problem.
> >>
> >>Test scripts are available at:
> >>https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc
> >>Test results are at:
> >>https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc
> >>
> >>Bisect log is attached.
> >>
> >>Please let me know if there is anything I can do to help tracking down the
> >>problem.
> >
> >Apologies!!! Does the patch below help?
> >
> No, sorry, it doesn't make a difference.
Interesting... Could you please send me the build failure messages?
Thanx, Paul
> Guenter
>
> > Thanx, Paul
> >
> >
> >
> >commit 97708e737e2a55fed4bdbc005bf05ea909df6b73
> >Author: Paul E. McKenney
> >Date: Tue Nov 29 11:06:05 2016 -0800
> >
> >rcu: Allow boot-time use of cond_resched_rcu_qs()
> >
> >The cond_resched_rcu_qs() macro is used to force RCU quiescent states
> > into
> >long-running in-kernel loops. However, some of these loops can execute
> >during early boot when interrupts are disabled, and during which time
> >it is therefore illegal to enter the scheduler. This commit therefore
> >makes cond_resched_rcu_qs() be a no-op during early boot.
> >
> >Signed-off-by: Paul E. McKenney
> >
> >diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> >index 525ca34603b7..b6944cc19a07 100644
> >--- a/include/linux/rcupdate.h
> >+++ b/include/linux/rcupdate.h
> >@@ -423,7 +423,7 @@ extern struct srcu_struct tasks_rcu_exit_srcu;
> > */
> > #define cond_resched_rcu_qs() \
> > do { \
> >-if (!cond_resched()) \
> >+if (!is_idle_task(current) && !cond_resched()) \
> > rcu_note_voluntary_context_switch(current); \
> > } while (0)
> >
> >diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> >index 7232d199a81c..20f5990d 100644
> >--- a/include/linux/rcutiny.h
> >+++ b/include/linux/rcutiny.h
> >@@ -228,6 +228,7 @@ static inline void exit_rcu(void)
> > extern int rcu_scheduler_active __read_mostly;
> > void rcu_scheduler_starting(void);
> > #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
> >+#define rcu_scheduler_active false
> > static inline void rcu_scheduler_starting(void)
> > {
> > }
> >
> >
>
Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64
On Wed, Nov 30, 2016 at 10:32:09AM +0530, Yury Norov wrote:
> On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote:
> > This series enables aarch64 with ilp32 mode, and as supporting work,
> > introduces ARCH_32BIT_OFF_T configuration option that is enabled for
> > existing 32-bit architectures but disabled for new arches (so 64-bit
> > off_t is is used by new userspace).
>
> Hi all,
>
> Steve Ellcey submitted glibc patches for ILP32:
> https://www.sourceware.org/ml/libc-alpha/2016-11/msg01071.html
> It implicitly assumes that kernel clears top halves of registers for
> all syscalls in assembly entry. That patches are going to be taken.
> It it happens, we will have no choice on kernel side how to clear top
> halves anymore.
Since a while ago, there's a package "arch-test" in Debian that empirically
enumerates architectures executable by the running kernel (and loaded
binfmts), by trying small test programs for each. The list of architectures
it knows does include arm64ilp32.
For most archs the test is just {write(1, "ok\n"); _exit(0);} unless there's
some difference from baseline that should be checked for, like dmb (ARMv7)
on armhf or mtvsrd (POWER8) on ppc64el. I could scribble in the top half of
a register to test the delousing, but it's not like alternate versions of
the ABI are expected in the wild...
There's another issue: name. A stalled request to add it to dpkg's cputable
(https://bugs.debian.org/824742) uses "arm64ilp32" and "arm64ilp32be" which
are unwieldy. Even the discussion uses "ilp32" -- probably too generic.
https://wiki.linaro.org/Platform/arm64-ilp32 mentions both. I've heard
"a32" somewhere. I have no stake here (I'm on the CC list as a x32 not arm
porter...), but if you want to choose a color for this bikeshed, the time
is now.
Meow!
--
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings. What should the
historians do?
Re: [PATCH KERNEL] xen/events: use xen_vcpu_id mapping for EVTCHNOP_status
On 23/11/16 13:38, Vitaly Kuznetsov wrote: > EVTCHNOP_status hypercall returns Xen's idea of vcpu id so we need to > compare it against xen_vcpu_id mapping, not the Linux cpu id. > > Suggested-by: Radim Krcmar > Signed-off-by: Vitaly Kuznetsov Applied to xen/tip.git for-linus-4.10 Juergen
Re: [PATCH v10 02/13] drm/mediatek: add *driver_data for different hardware settings
Hi YT,
On Fri, Nov 25, 2016 at 6:34 PM, YT Shen wrote:
>
> There are some hardware settings changed, between MT8173 & MT2701:
> DISP_OVL address offset changed, color format definition changed.
> DISP_RDMA fifo size changed.
> DISP_COLOR offset changed.
> MIPI_TX pll setting changed.
> And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
Sorry, I have not had time to thoroughly review the new patch set, but
one quick comment:
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 22a33ee..cfaa760 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -78,6 +78,10 @@ struct mtk_ddp_comp_funcs {
> struct drm_crtc_state *state);
> };
>
> +struct mtk_ddp_comp_driver_data {
> + unsigned int color_offset;
> +};
> +
> struct mtk_ddp_comp {
> struct clk *clk;
> void __iomem *regs;
> @@ -85,6 +89,7 @@ struct mtk_ddp_comp {
> struct device *larb_dev;
> enum mtk_ddp_comp_id id;
> const struct mtk_ddp_comp_funcs *funcs;
> + const struct mtk_ddp_comp_driver_data *data;
I want to avoid adding this generic pointer here to all mtk_ddp_comp,
since this is only used by the color component.
Instead, define color specific types:
struct mtk_disp_color_data {
unsigned int offset;
};
struct mtk_disp_color {
struct mtk_ddp_comp ddp_comp;
const struct mtk_disp_color_data *data;
};
Then, add another comp_type check and fetch the dev data in
mtk_drm_probe() or maybe mtk_ddp_comp_init().
-Dan
Re: [patch net / RFC] net: fec: increase frame size limitation to actually available buffer
> But I think it is not necessary since the driver don't support jumbo frame. Hardcoded 1522 raises two separate issues. (1) When DSA is in use, frames processed by FEC chip contain DSA tag and thus can be larger than hardcoded limit of 1522. This issue is not FEC-specific, any driver that hardcodes maximum frame size to 1522 (many do) will have this issue if used with DSA. Clean solution for this must take into account that difference between MTU and max frame size is no longer known at compile time. Actually this is the case even without DSA, due to VLANs: max frame size is (MTU + 18) without VLANs, but (MTU + 22) with VLANs. However currently drivers tend to ignore this and hardcode 22. With DSA, 22 is not enough, need to add switch-specific tag size to that. Not yet sure how to handle this. DSA-specific API to find out tag size could be added, but generic solution should handle all cases of dynamic difference between MTU and max frame size, not only DSA. (2) There is some demand to use larger frames for optimization purposes. FEC register fields that limit frame size are 14-bit, thus allowing frames up to (4k-1). I'm about to prepare a larger patch: - add ndo_change_mtu handler, allowing MTU up to (4k - overhead), - set MAX_FL / TRUNC_FL based on configured MTU, - if necessary, do buffer reallocation with larger buffers. Is this suitable for upstreaming? Is there any policy related to handling larger frames?
RE: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32 bit kernels.
> -Original Message-
> From: Cathy Avery [mailto:cav...@redhat.com]
> Sent: Wednesday, November 23, 2016 5:47 AM
> To: KY Srinivasan ; Haiyang Zhang
> ; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com
> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; linux-
> s...@vger.kernel.org
> Subject: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32 bit
> kernels.
>
> On a 32 bit kernel sizeof(void *) is not 64 bits as hv_mpb_array
> requires. Also the buffer needs to be cleared or the upper bytes
> will contain junk.
>
> Suggested-by: Vitaly Kuznetsov
> Signed-off-by: Cathy Avery
Thanks Cathy.
Reviewed-by: K. Y. Srinivasan
>
> ChangeLog:
>
> v1) Initial submission
> v2) Remove memset and replace kmalloc with kzalloc.
> ---
> drivers/scsi/storvsc_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 8ccfc9e..05526b7 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1495,9 +1495,9 @@ static int storvsc_queuecommand(struct Scsi_Host
> *host, struct scsi_cmnd *scmnd)
> if (sg_count) {
> if (sg_count > MAX_PAGE_BUFFER_COUNT) {
>
> - payload_sz = (sg_count * sizeof(void *) +
> + payload_sz = (sg_count * sizeof(u64) +
> sizeof(struct vmbus_packet_mpb_array));
> - payload = kmalloc(payload_sz, GFP_ATOMIC);
> + payload = kzalloc(payload_sz, GFP_ATOMIC);
> if (!payload)
> return SCSI_MLQUEUE_DEVICE_BUSY;
> }
> --
> 2.5.0
Re: [PATCH v3 4/5] thermal: rockchip: optimize the conversion table
Hey, On Mon, Nov 28, 2016 at 07:12:03PM +0800, Caesar Wang wrote: > + num = abs(table->id[mid].code - table->id[mid + 1].code); > + num *= temp - table->id[mid].temp; > + denom = table->id[mid + 1].temp - table->id[mid].temp; isn't the above 'mid + 1' off-by-one when mid ends being == table.length - 1? You would be accessing table->id[table.length], which is wrong memory access, no?
Re: [PATCH v3 3/5] thermal: rockchip: fixes invalid temperature case
Hello,
On Tue, Nov 29, 2016 at 09:59:28PM -0800, Brian Norris wrote:
> On Tue, Nov 29, 2016 at 09:02:42PM -0800, Eduardo Valentin wrote:
> > On Tue, Nov 29, 2016 at 01:57:45PM -0800, Brian Norris wrote:
> > > I was thinking while reviewing that the binary search serves more to
> > > complicate things than to help -- it's much harder to read (and validate
> > > that the loop termination logic is correct). And searching through a few
> > > dozen table entries doesn't really get much benefit from a O(n) ->
> > > O(log(n)) speed improvement.
> >
> > true. but if in your code path you do several walks in the table just to
> > check if parameters are valid, given that you could simply decide if
> > they are valid or not with simpler if condition, then, still worth, no?
> > :-)
>
> Yes, your suggestions seems like they would have made the code both (a
> little) more straightforward and efficient. But...
>
> > > Anyway, I'm not sure if you were thinking along the same lines as me.
> > >
> >
> > Something like that, except I though of something even simpler:
> > + if ((temp % table->step) != 0)
> > + return -ERANGE;
> >
> > If temp passes that check, then you go to the temp -> code conversion.
>
> ...that check isn't valid as of patch 4, where Caesar adds handling for
> intermediate steps. We really never should have been strictly snapping
> to the 5C steps in the first place; intermediate values are OK.
>
> So, we still need some kind of search to find the right step -- or
> closest bracketing range, to compute the interpolated value. We should
> only reject temperatures that are too high or too low for the ADC to
> represent.
Ok. got it. check small comment on patch 4 then.
>
>
> --- Side track ---
>
> BTW, when we're considering rejecting temperatures here: shouldn't this
> be fed back to the upper layers more nicely? We're improving the error
> handling for this driver in this series, but it still leaves things
> behaving a little odd. When I tested, I can do:
>
> ## set something obviously way too high
> echo 70 > trip_point_X_temp
>
> and get a 0 (success) return code from the sysfs write() syscall, even
> though the rockchip driver rejected it with -ERANGE. Is there really no
> way to feed back thermal range limits of a sensor to the of-thermal
> framework?
>
well, that is a bit strange to me. Are you sure you are returning the
-ERANGE? Because, my assumption is that the following of-thermal code
path would return the error code back to core:
328 if (data->ops->set_trip_temp) {
329 int ret;
330
331 ret = data->ops->set_trip_temp(data->sensor_data, trip,
temp);
332 if (ret)
333 return ret;
334 }
And this part of thermal core would return it back to sysfs layer:
757 ret = tz->ops->set_trip_temp(tz, trip, temperature);
758 if (ret)
759 return ret;
or am I missing something?
> Brian
Re: [LKP] [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c
Hi Paul,
Attached is the new dmesg.
On Wed, Nov 30, 2016 at 05:39:50AM +0800, Ye Xiaolong wrote:
On 11/29, Paul E. McKenney wrote:
On Tue, Nov 29, 2016 at 05:21:19PM +, Sudeep Holla wrote:
On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
wrote:
>
> FYI, we noticed the following commit:
>
> commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent
__alloc_pages_nodemask() RCU CPU stall warnings")
> https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next
>
> in testcase: boot
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 1G
>
> caused below changes:
>
[...]
> [8.953192] BUG: sleeping function called from invalid context at
mm/page_alloc.c:3746
> [8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
I am observing similar BUG/backtrace even on ARM64 platform.
Does the (untested) patch below help?
Thanx, Paul
Hi, Paul
I applied your patch on top of 2d66ccc "mm:
Prevent__alloc_pages_nodemask() RCU CPU stall warnings"(e7c1db7 turns to
2d66ccc in rcu/next branch now), here is the comparison of 6 times
testing, seems the BUG persists.
b70fa84d2eeef5f6be25633a2b is the commit id of commit "rcu: Allow
boot-time useof cond_resched_rcu_qs()"
testcase/path_params/tbox_group/run: boot/1/vm-vp-1G
2d66cccd73436ac9 b70fa84d2eeef5f6be25633a2b
--
6:60% 6:6
dmesg.BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c
The new dmesg looks like this:
[6.505611] Write protecting the kernel read-only data: 14336k
[6.507798] Freeing unused kernel memory: 544K (880001978000 -
880001a0)
[6.515634] Freeing unused kernel memory: 240K (880001dc4000 -
880001e0)
[6.524713] BUG: sleeping function called from invalid context at
mm/page_alloc.c:3746
[6.527327] in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: init
[6.528891] CPU: 1 PID: 1 Comm: init Not tainted 4.9.0-rc1-00048-gb70fa84 #1
[6.530604] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[6.533255] c9197b48 81472609 8800296a
02201200
[6.538069] c9197b60 810a85a3 8800364bc080
c9197bf0
[6.542821] 81190dce 8800296a 8800296a
8800296a
[6.548618] Call Trace:
[6.550675] [] dump_stack+0x63/0x8a
[6.554180] [] ___might_sleep+0xd3/0x120
[6.556720] [] __alloc_pages_nodemask+0x23e/0x300
[6.560427] [] alloc_pages_current+0x95/0x140
[6.564063] [] new_slab+0x3c0/0x5a0
[6.566516] [] ___slab_alloc+0x3a0/0x4b0
[6.570114] [] ? anon_vma_clone+0x63/0x1c0
[6.572672] [] ? alloc_set_pte+0x4f2/0x610
[6.576273] [] ? anon_vma_clone+0x63/0x1c0
[6.578824] [] __slab_alloc+0x20/0x40
[6.582348] [] kmem_cache_alloc+0x17f/0x1c0
[6.585971] [] anon_vma_clone+0x63/0x1c0
[6.588487] [] ? __split_vma+0x5c/0x1e0
[6.592159] [] __split_vma+0xc4/0x1e0
[6.594746] [] split_vma+0x24/0x30
[6.598248] [] mprotect_fixup+0x21c/0x270
[6.601130] [] do_mprotect_pkey+0x20c/0x300
[6.602739] [] SyS_mprotect+0x13/0x20
[6.604328] [] entry_SYSCALL_64_fastpath+0x1a/0xa9
SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.30:
No such file or directory
[6.609407] systemd[1]: RTC configured in localtime, applying delta of 480
minutes to system time.
[6.637736] random: fast init done
[6.693275] ip_tables: (C) 2000-2006 Netfilter Core Team
...
[7.553423] NFS: Registering the id_resolver key type
[7.555204] Key type id_resolver registered
[7.557629] Key type id_legacy registered
[7.570901] scsi 1:0:0:0: Attached scsi generic sg0 type 5
[7.572947] BUG: sleeping function called from invalid context at
mm/page_alloc.c:3746
[7.575717] in_atomic(): 1, irqs_disabled(): 0, pid: 251, name: modprobe
[7.577496] CPU: 1 PID: 251 Comm: modprobe Tainted: GW
4.9.0-rc1-00048-gb70fa84 #1
[7.585286] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Debian-1.8.2-1 04/01/2014
[7.593093] c95e3b78 81472609 88003f33c900
02000200
[7.597043] c95e3b90 810a85a3 8800364bc080
c95e3c20
[7.599790] 81190dce 88003f33c900 88003f33c900
88003f33c900
[7.608630] Call Trace:
[7.609787] [] dump_stack+0x63/0x8a
[7.611366] [] ___might_sleep+0xd3/0x120
[7.614373] [] __alloc_pages_nodemask+0x23e/0x300
[7.622141] [] alloc_pages_current+0x95/0x140
[7.623754] [] __get_free_pages+0xe/0x40
[7.625323] [] __tlb_remove_page_size+0x53/0x90
[7.627086] [] unmap_page_range+0x6cb/0x910
[7.628647] [] ? release_pages+0x2fc/0x390
[7.630242] [] unmap_single_vma+0x7d/0xe0
[7.631725] [] unmap_vmas+0x51/0xa0
[7.63313
Re: bnx2 breaks Dell R815 BMC IPMI since 4.8
Le 30 novembre 2016 00:28:08 GMT+01:00, Gavin Shan a écrit : >On Tue, Nov 29, 2016 at 07:57:51AM +0100, Brice Goglin wrote: >>Hello >> >>My Dell PowerEdge R815 doesn't have IPMI anymore when I boot a 4.8 >>kernel, the BMC doesn't even ping anymore. Its Ethernet devices are 4 >of >>those: >> >>01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 >Gigabit Ethernet (rev 20) >> DeviceName: Embedded NIC 1 >> Subsystem: Dell NetXtreme II BCM5709 Gigabit Ethernet >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >SERR- > Latency: 0, Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 42 >> Region 0: Memory at e600 (64-bit, non-prefetchable) [size=32M] >> Capabilities: >> Kernel driver in use: bnx2 >> Kernel modules: bnx2 >> >>The only change in bnx2 between 4.7 and 4.8 appears to be this one: >> >>commit 3e1be7ad2d38c6bd6aeef96df9bd0a7822f4e51c >>Author: Baoquan He >>Date: Fri Sep 9 22:43:12 2016 +0800 >> >>bnx2: Reset device during driver initialization >> >>Could you patch actually break the BMC? What do I need to further >debug >>this issue? >> > >Brice, could you please confirm NCSI is enabled on BMC? It seems NCSI >AEN pakets aren't handled by NCSI stack on BMC side when resetting NIC >on host side. Those AEN packets usually help to reconfigure the >(active) >NCSI channel and bring it back to service after the reset. I don't remember ever seeing the name NCSI in those Dell BMC configs. Any other word to look for? By the way, the bug is gone in 4.8.11. Brice
[PATCH] serial: 8250_mid fix calltrace when hotplug 8250 serial controller
From: Liwei Song
Fix the following Calltrace:
[ 77.768221] WARNING: CPU: 5 PID: 645 at drivers/dma/dmaengine.c:1069
dma_async_device_unregister+0xe2/0xf0
[ 77.775058] dma_async_device_unregister called while 1 clients hold a
reference
[ 77.825048] CPU: 5 PID: 645 Comm: sh Not tainted 4.8.8-WR9.0.0.0_standard+ #3
[ 77.832550] Hardware name: Intel Corp. Aspen Cove/Server, BIOS
HAVLCRB1.X64.0012.D58.1604140405 04/14/2016
[ 77.840396] c90008adbc80 81403456
c90008adbcd0
[ 77.848245] c90008adbcc0 8105e2e1
042d08adbf20
[ 77.855934] 88046a861c18 88046a85c420 820d4200
88046ae92318
[ 77.863601] Call Trace:
[ 77.871113] [] dump_stack+0x4f/0x69
[ 77.878655] [] __warn+0xd1/0xf0
[ 77.886102] [] warn_slowpath_fmt+0x4f/0x60
[ 77.893508] [] ? find_next_bit+0x19/0x20
[ 77.900730] [] ? dma_channel_rebalance+0x23e/0x270
[ 77.907814] [] dma_async_device_unregister+0xe2/0xf0
[ 77.914992] [] hsu_dma_remove+0x1a/0x60
[ 77.921977] [] dnv_exit+0x1c/0x20
[ 77.928752] [] mid8250_remove+0x26/0x40
[ 77.935607] [] pci_device_remove+0x39/0xc0
[ 77.942292] [] __device_release_driver+0x9a/0x140
[ 77.948836] [] device_release_driver+0x23/0x30
[ 77.955364] [] pci_stop_bus_device+0x8c/0xa0
[ 77.961769] []
pci_stop_and_remove_bus_device_locked+0x1a/0x30
[ 77.968113] [] remove_store+0x5e/0x70
[ 77.974267] [] dev_attr_store+0x18/0x30
[ 77.980243] [] sysfs_kf_write+0x3a/0x50
[ 77.986180] [] kernfs_fop_write+0x10b/0x190
[ 77.992118] [] __vfs_write+0x18/0x40
[ 77.998032] [] vfs_write+0xae/0x190
[ 78.003747] [] SyS_write+0x46/0xb0
[ 78.009234] [] entry_SYSCALL_64_fastpath+0x13/0x8f
[ 78.014809] ---[ end trace 0c36dd73b7408eb2 ]---
This happens when the 8250 serial controller is hotplugged as follows:
echo 1 > /sys/bus/pci/devices/:00:1a.0/remove
This trace happens due to the serial port still holding a reference when
the dma device is unregistered.
The dma unregister routine will check if there is still a reference exist,
if so it will give the WARNING(here serial port still was not unregister).
To fix this, We need to unregister the serial port first, then do DMA
device unregister to make sure there is no reference when to DMA routine.
Signed-off-by: Liwei Song
---
drivers/tty/serial/8250/8250_mid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_mid.c
b/drivers/tty/serial/8250/8250_mid.c
index 39c2324..ac013edf 100644
--- a/drivers/tty/serial/8250/8250_mid.c
+++ b/drivers/tty/serial/8250/8250_mid.c
@@ -303,10 +303,10 @@ static void mid8250_remove(struct pci_dev *pdev)
{
struct mid8250 *mid = pci_get_drvdata(pdev);
+ serial8250_unregister_port(mid->line);
+
if (mid->board->exit)
mid->board->exit(mid);
-
- serial8250_unregister_port(mid->line);
}
static const struct mid8250_board pnw_board = {
--
2.9.3
Re: [PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX
* Alex Thorlton wrote: > It's really not necessary to limit E820_X_MAX to 128 in the non-EFI > case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that > E820_X_MAX is always at least slightly larger than E820MAX. > > The real motivation behind this is actually to prevent some issues in > the Xen kernel, where the XENMEM_machine_memory_map hypercall can > produce an e820 map larger than 128 entries, even on systems where the > original e820 table was quite a bit smaller than that, depending on how > many IOAPICs are installed on the system. > > Signed-off-by: Alex Thorlton > Suggested-by: Ingo Molnar > Cc: Russ Anderson > Cc: David Vrabel > Cc: Ingo Molnar > Cc: Juergen Gross > Cc: Thomas Gleixner > Cc: "H. Peter Anvin" > Cc: Denys Vlasenko > Cc: Boris Ostrovsky > Cc: x...@kernel.org > Cc: xen-de...@lists.xenproject.org > --- > arch/x86/include/asm/e820.h | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/include/asm/e820.h b/arch/x86/include/asm/e820.h > index 476b574..aa00d33 100644 > --- a/arch/x86/include/asm/e820.h > +++ b/arch/x86/include/asm/e820.h > @@ -1,13 +1,15 @@ > #ifndef _ASM_X86_E820_H > #define _ASM_X86_E820_H > > -#ifdef CONFIG_EFI > +/* > + * We need to make sure that E820_X_MAX is defined > + * before we include uapi/asm/e820.h > + */ > #include > #define E820_X_MAX (E820MAX + 3 * MAX_NUMNODES) What we need an explanation for in the comment is what does this stand for (what does the 'X' mean?), and what is the magic 3*MAX_NUMNODES about? Thanks, Ingo
Re: [PATCH 17/39] mtd: nand: denali: support HW_ECC_FIXUP capability
Hi Boris,
2016-11-28 1:09 GMT+09:00 Boris Brezillon :
&max_bitflips);
>
> Okay, so you currently have two ways of handling ECC errors. What if a
> new revision introduces yet another way to do it?
>
> How about making denali_caps a structure where you have one (or several)
> function pointers to implement operations differently depending on the
> IP revision?
>
> struct denali_caps {
> u32 feature_flags; /* If needed. */
> bool (*handle_ecc)(...);
> ...
> };
>
I think a problem is the difference of function arguments:
static bool denali_hw_ecc_fixup(struct denali_nand_info *denali,
unsigned int *max_bitflips)
vs
static bool denali_sw_ecc_fixup(struct denali_nand_info *denali, u8 *buf,
u32 irq_status, unsigned int *max_bitflips)
I do not want to pass redundant arguments,
which are used for one, but not used for the other.
We do not need to think about the situation that may not happen.
If happens, we can refactor the code any time.
--
Best Regards
Masahiro Yamada
Re: [PATCH 20/39] mtd: nand: denali_dt: enable HW_ECC_FIXUP capability for DT platform
Hi Boris, 2016-11-28 1:14 GMT+09:00 Boris Brezillon : > On Sun, 27 Nov 2016 03:06:06 +0900 > Masahiro Yamada wrote: > >> The denali_dt.c was split out by Altera for the SOCFPGA port. The >> Denali IP on SOCFPGA incorporates the hardware ECC fixup feature. >> Newer versions are very likely to support it. So, it should be OK >> to set DENALI_CAPS_HW_ECC_FIXUP for all DT platforms. > > Seems like a bad idea. What's the problem with setting this flag in the > data->caps definition of each revision? No problem. I will follow your suggestion in v2. -- Best Regards Masahiro Yamada
Re: [PATCH V4] PM / OPP: Pass opp_table to dev_pm_opp_put_regulator()
Hi Viresh, On 11/30/2016 12:59 PM, Viresh Kumar wrote: > From: Stephen Boyd > > Joonyoung Shim reported an interesting problem on his ARM octa-core > Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator() > was failing for a struct device for which dev_pm_opp_set_regulator() is > called earlier. > > This happened because an earlier call to > dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file) > removed all the entries from opp_table->dev_list apart from the last CPU > device in the cpumask of CPUs sharing the OPP. > > But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator() > routines get CPU device for the first CPU in the cpumask. And so the OPP > core failed to find the OPP table for the struct device. > > In order to fix that up properly, we need to revisit APIs like > dev_pm_opp_set_regulator() and make them talk in terms of cookies > provided by the OPP core. But such a solution will be hard to backport > to stable kernels. > > This patch attempts to fix this problem by returning a pointer to the > opp_table from dev_pm_opp_set_regulator() and using that as the > parameter to dev_pm_opp_put_regulator(). This ensures that the > dev_pm_opp_put_regulator() doesn't fail to find the opp table. > > Note that similar design problem also exists with other > dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and > so we don't need to update them for now. > > [Viresh]: Written commit log, minor improvements in the patch and tested > on exynos 5250. > > Cc: # v4.4+ > Reported-by: Joonyoung Shim > Signed-off-by: Stephen Boyd > Signed-off-by: Viresh Kumar > --- > V3->V4: > - Completely different approach, suggested earlier by Stephen. > - Can be merged safely now as both /me and Stephen agree to this one. > > @Joonyoung: Can you please test this last patch please ? > Just system suspend/resume is working but i was missing below test case that you inform when i test for prior patches on my Odroid-XU3 board. - offline CPU 4 - suspend the system With this test case, now all patches posted have the problem that is failed to get clk: -2. If all CPUs are online, cpufreq_driver->init(policy) is called by cpufreq_online() only for CPU0 and CPU4 during system resume but it is called for CPU5, CPU6 and CPU7 during system resume after CPU4 is offline, and causes error. Please refer below logs. # echo 0 > /sys/devices/system/cpu/cpu4/online [ 145.438931] IRQ54 no longer affine to CPU4 [ 145.439931] CPU4: shutdown # # # rtcwake -m mem -s 3 wakeup from "mem" at Mon Apr 9 11:04:19 2001 [ 148.708773] PM: Syncing filesystems ... done. [ 148.718591] Freezing user space processes ... (elapsed 0.005 seconds) done. [ 148.727749] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. [ 148.753406] wake enabled for irq 135 [ 148.754006] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode [ 148.844402] PM: suspend of devices complete after 100.196 msecs [ 148.869158] PM: late suspend of devices complete after 19.793 msecs [ 148.891948] PM: noirq suspend of devices complete after 17.803 msecs [ 148.897067] Disabling non-boot CPUs ... [ 148.920201] IRQ51 no longer affine to CPU1 [ 148.921414] CPU1: shutdown [ 148.990114] IRQ52 no longer affine to CPU2 [ 148.991158] CPU2: shutdown [ 149.049416] IRQ53 no longer affine to CPU3 [ 149.050477] CPU3: shutdown [ 149.114297] IRQ55 no longer affine to CPU5 [ 149.115318] CPU5: shutdown [ 149.184539] IRQ56 no longer affine to CPU6 [ 149.185421] CPU6: shutdown [ 149.257561] IRQ57 no longer affine to CPU7 [ 149.258458] CPU7: shutdown exynos_suspend_enter: suspending the system... exynos_suspend_enter: wakeup masks: fffd,ffef UART[f702]: ULCON=0003, UCON=f3c5, UFCON=0131, UBRDIV=001b [ 149.295339] Enabling non-boot CPUs ... [ 149.314454] CPU1 is up [ 149.329717] CPU2 is up [ 149.350140] CPU3 is up [ 149.370365] cpu cpu5: cpufreq_init: failed to get clk: -2 [ 149.374803] IRQ55 no longer affine to CPU5 [ 149.375126] CPU5: shutdown [ 149.399737] Error taking CPU5 up: -2 [ 149.425424] cpu cpu6: cpufreq_init: failed to get clk: -2 [ 149.429886] IRQ56 no longer affine to CPU6 [ 149.430242] CPU6: shutdown [ 149.454745] Error taking CPU6 up: -2 [ 149.480397] cpu cpu7: cpufreq_init: failed to get clk: -2 [ 149.484869] IRQ57 no longer affine to CPU7 [ 149.485186] CPU7: shutdown [ 149.509718] Error taking CPU7 up: -2 [ 149.512392] s3c-i2c 12c6.i2c: slave address 0x00 [ 149.516787] s3c-i2c 12c6.i2c: bus frequency set to 65 KHz [ 149.522554] s3c-i2c 12c8.i2c: slave address 0x00 [ 149.527461] s3c-i2c 12c8.i2c: bus frequency set to 65 KHz [ 149.535818] PM: noirq resume of devices complete after 23.970 msecs [ 149.543853] PM: early resume of devices complete after 3.020 msecs [ 149.571356] s3c2410-wdt 101d.watchdog: watchdog disabled [ 149.575811] usb usb1: root hub lost power or was reset [ 149.641026] usb usb2: root hub lost power or was reset
RE: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32 bit kernels.
> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Tuesday, November 29, 2016 8:58 AM > To: Cathy Avery > Cc: KY Srinivasan ; Haiyang Zhang > ; j...@linux.vnet.ibm.com; > martin.peter...@oracle.com; de...@linuxdriverproject.org; linux- > ker...@vger.kernel.org; linux-s...@vger.kernel.org > Subject: Re: [PATCH v2] [hv] storvsc: Payload buffer incorrectly sized for 32 > bit kernels. > > > "Cathy" == Cathy Avery writes: > > Cathy> On a 32 bit kernel sizeof(void *) is not 64 bits as hv_mpb_array > Cathy> requires. Also the buffer needs to be cleared or the upper bytes > Cathy> will contain junk. > > K.Y.: Please review! Done. K. Y > > -- > Martin K. PetersenOracle Linux Engineering
Re: [PATCH 18/39] mtd: nand: denali: move denali_read_page_raw() above denali_read_page()
Hi Boris, 2016-11-28 1:10 GMT+09:00 Boris Brezillon : > On Sun, 27 Nov 2016 03:06:04 +0900 > Masahiro Yamada wrote: > >> This will be needed in the next commit to call denali_read_page_raw() >> from denali_read_page(). > > Please squash this change into patch 19. It's clearly useless to > dissociate them. > I will. But as I mentioned in the reply to 19/39, I am thinking that another solution may be possible. In that case, both 18/39 and 19/39 will be unnecessary. -- Best Regards Masahiro Yamada
Re: [PATCH 28/39] mtd: nand: denali: move multi NAND fixup code to a helper function
Hi Boris, 2016-11-28 1:24 GMT+09:00 Boris Brezillon : > On Sun, 27 Nov 2016 03:06:14 +0900 > Masahiro Yamada wrote: > >> Collect multi NAND fixups into a helper function instead of >> scattering them in denali_init(). > > Can you tell me more about this multi-NAND feature? > The core is already able to detect multi-die NAND chips in a generic > way, This is not the case. > but I fear this is something else, like "put two 8-bits chips on a > 16bits bus to emulate a single 16bits chip". Yes, it is. (I have never used this controller like that. But, I am pretty sure it is from the code and the Denali's User Guide mentions such usage.) Just in case, I will clearly rephrase the comment block like follows in v2: /* * Support for multi device: * When the IP configuration is x16 capable and two x8 chips are * connected in parallel, DEVICES_CONNECTED should be set to 2. * In this case, the core framework knows nothing about this fact, * so we should tell it the _logical_ pagesize and anything necessary. */ > If that's a case, and this feature is actually used, then it's a bad > idea IMHO. > For example, how do you handle the case where one block is bad on a > chip but not on the other? And I fear this is not the only problem > with this approach :-/. As you expect, if one block is bad, the correspond block on the other chip can not be used. -- Best Regards Masahiro Yamada
Re: [PATCH V2 09/10] thermal: da9062/61: Thermal junction temperature monitoring driver
Hey Steve,
On Tue, Nov 29, 2016 at 11:11:59AM +, Steve Twiss wrote:
> Hi Eduardo,
>
> Thanks for your response.
>
> On 29 November 2016 01:24, Eduardo Valentin, wrote:
>
> > On Wed, Oct 26, 2016 at 05:56:39PM +0100, Steve Twiss wrote:
> > > +config DA9062_THERMAL
> > > + tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
> > > + depends on MFD_DA9062
> > > + depends on OF
> > > + help
> > > + Enable this for the Dialog Semiconductor thermal sensor driver.
> > > + This will report PMIC junction over-temperature for one thermal trip
> > > + zone.
> > > + Compatible with the DA9062 and DA9061 PMICs.
> >
> > Is there any hardware documentation available for this chip that can be
> > pointed out?
>
> As part of this patch set, I added a link to the the datasheet into the
> top-level MFD
> component of the device tree binding:
> https://patchwork.kernel.org/patch/9426791/
> You can get all the information for DA9062 and DA9061 from the patch update
> in that
> link.
Thanks for getting me up to speed.
>
> [...]
> > Does this mean that the chip temperature is above or equal to 125C, is
> > this really a safe temperature to keep it running?
>
> There is more information in the datasheet under the section titles "Junction
> temperature supervision". The value of 125 degC comes from the "warning
> temperature threshold" and the event is triggered when "the junction
> temperature
> rises above the first threshold (TEMP_WARN), the event E_TEMP is asserted".
>
> This suggests strictly greater than 125. However, there is no way for the
> chip to
> know the exact temperature. The mechanism is interrupt based and triggering
> only happens when the temperature rises above the threshold level.
Understood. My original concern was if the driver would be too nice with
the event. But given that the hardware has its own shutdown protection,
looks like we are OK here.
>
> [...]
> > > +static irqreturn_t da9062_thermal_irq_handler(int irq, void *data)
> > > +{
> > > + struct da9062_thermal *thermal = data;
> > > +
> > > + disable_irq_nosync(thermal->irq);
> > > + schedule_delayed_work(&thermal->work, 0);
> >
> > Can you please elaborate a little on why you have an one shot threaded IRQ
> > handler that is only disabling the IRQ then, scheduling a work with delay
> > of 0?
> >
> > To my understanding, this is exactly what you get when you run your
> > threaded IRQ handler, when you configure it as one shot.
> >
> > Have you tried simply handling the same work done in your workqueue
> > handler in your threaded IRQ? That should simplify your code and get the
> > same result you are expecting.
> >
> > If you are not getting the IRQ disabled on the threaded IRQ when
> > configured as one shot, something else seams to be broken.
>
> Over-temperature triggering is event based: an interrupt happens when the
> temperature rises above 125 degC. However, this event based system changes
> into
> a polling operation to detect when the temperature falls below the threshold
> level again. This asymmetry in the chip's behaviour is the reasoning behind
> why I am not using the thermal core's built-in polling functionality.
>
> When over-temperature is reached, the interrupt from the DA9061/2 will be
> repeatedly triggered. The IRQ is disabled when the first over-temperature
> event
> happens and the status bit is polled using the work-queue until it becomes
> false.
> After that, the IRQ is re-enabled again so a new critical temperature event
> can
> be detected.
>
> After the interrupt has happened, event bit for the interrupt switches into a
> status
> bit and is used for polling and detecting when the temperature drops below the
> threshold.
OK. got it. Then, I am assuming your strategy here is to keep periodically
issuing uevents
(HOT trip point) to userland, hoping that something would change the
system power consumption, then, relying on the hardware shutdown protection
if nothing happens.
I would say, your above explanation, and the uevent based strategy,
deserves to be at least in the commit message, preferably in the driver
documentation, so people know what to expect from the driver.
Now, if my understand is correct, would it make sense to have still a
failsafe mechanism in the driver? Maybe having a max number of polling?
The data sheet does not mention anything, but does one have any silicon
lifetime implication if one leaves the PMIC running for very long time
in a temperature between Twarn and Tcrit?
>
> https://lkml.org/lkml/2016/10/20/372
> https://lkml.org/lkml/2016/10/20/433
>
> [...]
> > > + thermal->zone = thermal_zone_device_register(thermal->config->name,
> > > + 1, 0, thermal,
> > > + &da9062_thermal_ops, NULL, 0,
> > > + 0);
> >
> > Did you try using of-thermal?
> >
> > So you would avoid having specific DT properties for something that
> > there is already a defi
[PATCH 2/2] Synopsys USB 2.0 Device Controller (UDC) Driver
This is driver for Synopsys Designware Cores USB Device
Controller (UDC) Subsystem with the AMBA Advanced High-Performance
Bus (AHB). This driver works with Synopsys UDC20 products.
Signed-off-by: Raviteja Garimella
---
drivers/usb/gadget/udc/Kconfig| 12 +
drivers/usb/gadget/udc/Makefile |1 +
drivers/usb/gadget/udc/snps_udc.c | 1751 +
drivers/usb/gadget/udc/snps_udc.h | 1071 +++
4 files changed, 2835 insertions(+)
create mode 100644 drivers/usb/gadget/udc/snps_udc.c
create mode 100644 drivers/usb/gadget/udc/snps_udc.h
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 658b8da..28cd679 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -239,6 +239,18 @@ config USB_MV_U3D
MARVELL PXA2128 Processor series include a super speed USB3.0 device
controller, which support super speed USB peripheral.
+config USB_SNP_UDC
+ tristate "Synopsys USB 2.0 Device controller"
+ select USB_GADGET_DUALSPEED
+ depends on (ARM || ARM64) && USB_GADGET
+ default ARCH_BCM_IPROC
+ help
+ This adds Device support for Synopsys Designware core
+ AHB subsystem USB2.0 Device Controller(UDC) .
+
+ This driver works with Synopsys UDC20 products.
+ If unsure, say N.
+
#
# Controllers available in both integrated and discrete versions
#
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index 98e74ed..2b63a2b 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -36,4 +36,5 @@ obj-$(CONFIG_USB_FOTG210_UDC) += fotg210-udc.o
obj-$(CONFIG_USB_MV_U3D) += mv_u3d_core.o
obj-$(CONFIG_USB_GR_UDC) += gr_udc.o
obj-$(CONFIG_USB_GADGET_XILINX)+= udc-xilinx.o
+obj-$(CONFIG_USB_SNP_UDC) += snps_udc.o
obj-$(CONFIG_USB_BDC_UDC) += bdc/
diff --git a/drivers/usb/gadget/udc/snps_udc.c
b/drivers/usb/gadget/udc/snps_udc.c
new file mode 100644
index 000..d8c46ce
--- /dev/null
+++ b/drivers/usb/gadget/udc/snps_udc.c
@@ -0,0 +1,1751 @@
+/*
+ * snps_udc.c - Synopsys USB 2.0 Device Controller driver
+ *
+ * Copyright (C) 2016 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "snps_udc.h"
+
+#define DRIVER_DESC "Driver for Synopsys Designware core UDC"
+
+static void ep0_setup_init(struct snps_udc_ep *ep, int status)
+{
+ struct snps_udc *udc = ep->udc;
+
+ ep->dma.virt->setup.status = DMA_STS_BUF_HOST_READY;
+ ep->dirn = USB_DIR_OUT;
+ ep->stopped = 0;
+
+ if (!status) {
+ clear_ep_nak(udc->regs, ep->num, USB_DIR_OUT);
+ clear_ep_nak(udc->regs, ep->num, USB_DIR_IN);
+ } else {
+ enable_ep_stall(udc->regs, ep->num, USB_DIR_IN);
+ enable_ep_stall(udc->regs, ep->num, USB_DIR_OUT);
+ }
+
+ enable_udc_ep_irq(udc->regs, ep->num, USB_DIR_OUT);
+ enable_ep_dma(udc->regs, ep->num, USB_DIR_OUT);
+
+ dev_dbg(udc->dev, "%s setup buffer initialized\n", ep->name);
+}
+
+static void ep_dma_init(struct snps_udc_ep *ep)
+{
+ struct snps_udc *udc = ep->udc;
+ u32 desc_cnt = (DESC_CNT - 1);
+ u32 i;
+
+ ep->dma.virt = &ep->udc->dma.virt->ep[ep->num];
+ ep->dma.phys = &ep->udc->dma.phys->ep[ep->num];
+
+ ep->dma.virt->setup.status = DMA_STS_BUF_HOST_BUSY;
+ set_setup_buf_ptr(udc->regs, ep->num, USB_DIR_OUT,
+ &ep->dma.phys->setup);
+
+ for (i = 0; i < DESC_CNT; i++) {
+ ep->dma.virt->desc[i].status = DMA_STS_BUF_HOST_BUSY;
+ ep->dma.virt->desc[i].next_desc_addr =
+ (dma_addr_t)&ep->dma.phys->desc[i + 1];
+ }
+ ep->dma.virt->desc[desc_cnt].next_desc_addr =
+ (dma_addr_t)&ep->dma.phys->desc[0];
+
+ set_data_desc_ptr(udc->regs, ep->num, USB_DIR_OUT,
+ &ep->dma.phys->desc[0]);
+ set_data_desc_ptr(udc->regs, ep->num, USB_DIR_IN,
+ &ep->dma.phys->desc[0]);
+
+ dev_dbg(udc->dev, " %s dma initialized\n", ep->name);
+}
+
+static void ep_data_dma_init(struct snps_udc_ep *ep)
+{
+ struct ep_xfer_req *ep_req;
+
+ dev_dbg(ep->udc->dev, "enter: %s\n", __func__);
+
+ ep_req = list_first
[PATCH 1/2] Add DT bindings documentation for Synopsys UDC driver
This patch adds documentation for Synopsis Designware Cores AHB
Subsystem Device Controller (UDC).
Signed-off-by: Raviteja Garimella
---
.../devicetree/bindings/usb/snps,dw-ahb-udc.txt| 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
diff --git a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
new file mode 100644
index 000..64e1fbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
@@ -0,0 +1,29 @@
+Synopsys USB Device controller.
+
+The device node is used for Synopsys Designware Cores AHB
+Subsystem Device Controller (UDC).
+
+Required properties:
+ - compatible: should be "snps,dw-ahbudc"
+ - reg: Offset and length of UDC register set
+ - interrupts: description of interrupt line
+ - phys: phandle to phy node.
+ - phy-names: name of phy node. Must be usb2drd.
+ - extcon: phandle to the extcon device
+
+Example:
+
+ usbdrd_phy: phy@6501c000 {
+ #phy-cells = <0>;
+ compatible = "brcm,ns2-drd-phy";
+ reg = <0x6600 0x1000>,
+ }
+
+ udc_dwc: usb@664e {
+ compatible = "snps,dw-ahb-udc";
+ reg = <0x664e 0x2000>;
+ interrupts = ;
+ phys = <&usbdrd_phy>;
+ phy-names = "usb2drd";
+ extcon = <&usbdrd_phy>";
+ };
--
2.1.0
[PATCH 0/2] Support for Synopsys UDC for ARM platforms
This patchset adds support for Synposys Designware core AHB-UDC (USB Device controller) for Arm platfoms. New UDC driver is added to drivers/usb/gadget directory along with updating the Kconfig and Makefile. DT bindings documentation is also added for the same. Device tree entry for the same in NS2 dtsi will be sent for review once the DRD phy driver code is pushed (which is being reviewed in a separate patch series). This patchset is tested on Broadcom NS2 BCM958712K reference board. Repo: https://github.com/Broadcom/arm64-linux.git Branch: udc_v1 Raviteja Garimella (2): Add DT bindings documentation for Synopsys UDC driver Synopsys USB 2.0 Device Controller (UDC) Driver .../devicetree/bindings/usb/snps,dw-ahb-udc.txt| 29 + drivers/usb/gadget/udc/Kconfig | 12 + drivers/usb/gadget/udc/Makefile|1 + drivers/usb/gadget/udc/snps_udc.c | 1751 drivers/usb/gadget/udc/snps_udc.h | 1071 5 files changed, 2864 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt create mode 100644 drivers/usb/gadget/udc/snps_udc.c create mode 100644 drivers/usb/gadget/udc/snps_udc.h -- 2.1.0
[PATCH 02/12] phy: sun4i-usb: Replace the deprecated extcon API
This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()
Cc: Kishon Vijay Abraham I
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Signed-off-by: Chanwoo Choi
---
drivers/phy/phy-sun4i-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index eeda5134c777..95cdb08c339f 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -528,7 +528,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
mutex_unlock(&phy0->mutex);
if (id_notify) {
- extcon_set_cable_state_(data->extcon, EXTCON_USB_HOST,
+ extcon_set_state_sync(data->extcon, EXTCON_USB_HOST,
!id_det);
/* When leaving host mode force end the session here */
if (force_session_end && id_det == 1) {
@@ -541,7 +541,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
work_struct *work)
}
if (vbus_notify)
- extcon_set_cable_state_(data->extcon, EXTCON_USB, vbus_det);
+ extcon_set_state_sync(data->extcon, EXTCON_USB, vbus_det);
if (sun4i_usb_phy0_poll(data))
queue_delayed_work(system_wq, &data->detect, POLL_TIME);
--
1.9.1
[PATCH 06/12] usb: dwc3: omap: Replace the extcon API
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/dwc3/dwc3-omap.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 29e80cc9b634..2d2e9aa1db08 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -425,20 +425,20 @@ static int dwc3_omap_extcon_register(struct dwc3_omap
*omap)
}
omap->vbus_nb.notifier_call = dwc3_omap_vbus_notifier;
- ret = extcon_register_notifier(edev, EXTCON_USB,
- &omap->vbus_nb);
+ ret = devm_extcon_register_notifier(omap->dev, edev,
+ EXTCON_USB, &omap->vbus_nb);
if (ret < 0)
dev_vdbg(omap->dev, "failed to register notifier for
USB\n");
omap->id_nb.notifier_call = dwc3_omap_id_notifier;
- ret = extcon_register_notifier(edev, EXTCON_USB_HOST,
- &omap->id_nb);
+ ret = devm_extcon_register_notifier(omap->dev, edev,
+ EXTCON_USB_HOST, &omap->id_nb);
if (ret < 0)
dev_vdbg(omap->dev, "failed to register notifier for
USB-HOST\n");
- if (extcon_get_cable_state_(edev, EXTCON_USB) == true)
+ if (extcon_get_state(edev, EXTCON_USB) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
- if (extcon_get_cable_state_(edev, EXTCON_USB_HOST) == true)
+ if (extcon_get_state(edev, EXTCON_USB_HOST) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
omap->edev = edev;
@@ -527,17 +527,13 @@ static int dwc3_omap_probe(struct platform_device *pdev)
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(&pdev->dev, "failed to create dwc3 core\n");
- goto err2;
+ goto err1;
}
dwc3_omap_enable_irqs(omap);
return 0;
-err2:
- extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
- extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
-
err1:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
@@ -549,8 +545,6 @@ static int dwc3_omap_remove(struct platform_device *pdev)
{
struct dwc3_omap*omap = platform_get_drvdata(pdev);
- extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
- extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
dwc3_omap_disable_irqs(omap);
of_platform_depopulate(omap->dev);
pm_runtime_put_sync(&pdev->dev);
--
1.9.1
[PATCH 08/12] usb: phy: msm: Replace the extcon API
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/phy/phy-msm-usb.c | 33 +++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8a34759727bb..a15a89d4235d 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1742,14 +1742,14 @@ static int msm_otg_read_dt(struct platform_device
*pdev, struct msm_otg *motg)
if (!IS_ERR(ext_vbus)) {
motg->vbus.extcon = ext_vbus;
motg->vbus.nb.notifier_call = msm_otg_vbus_notifier;
- ret = extcon_register_notifier(ext_vbus, EXTCON_USB,
- &motg->vbus.nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, ext_vbus,
+ EXTCON_USB, &motg->vbus.nb);
if (ret < 0) {
dev_err(&pdev->dev, "register VBUS notifier failed\n");
return ret;
}
- ret = extcon_get_cable_state_(ext_vbus, EXTCON_USB);
+ ret = extcon_get_state(ext_vbus, EXTCON_USB);
if (ret)
set_bit(B_SESS_VLD, &motg->inputs);
else
@@ -1759,16 +1759,14 @@ static int msm_otg_read_dt(struct platform_device
*pdev, struct msm_otg *motg)
if (!IS_ERR(ext_id)) {
motg->id.extcon = ext_id;
motg->id.nb.notifier_call = msm_otg_id_notifier;
- ret = extcon_register_notifier(ext_id, EXTCON_USB_HOST,
- &motg->id.nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, ext_id,
+ EXTCON_USB_HOST, &motg->id.nb);
if (ret < 0) {
dev_err(&pdev->dev, "register ID notifier failed\n");
- extcon_unregister_notifier(motg->vbus.extcon,
- EXTCON_USB, &motg->vbus.nb);
return ret;
}
- ret = extcon_get_cable_state_(ext_id, EXTCON_USB_HOST);
+ ret = extcon_get_state(ext_id, EXTCON_USB_HOST);
if (ret)
clear_bit(ID, &motg->inputs);
else
@@ -1883,10 +1881,9 @@ static int msm_otg_probe(struct platform_device *pdev)
*/
if (motg->phy_number) {
phy_select = devm_ioremap_nocache(&pdev->dev, USB2_PHY_SEL, 4);
- if (!phy_select) {
- ret = -ENOMEM;
- goto unregister_extcon;
- }
+ if (!phy_select)
+ return -ENOMEM;
+
/* Enable second PHY with the OTG port */
writel(0x1, phy_select);
}
@@ -1897,7 +1894,7 @@ static int msm_otg_probe(struct platform_device *pdev)
if (motg->irq < 0) {
dev_err(&pdev->dev, "platform_get_irq failed\n");
ret = motg->irq;
- goto unregister_extcon;
+ return motg->irq;
}
regs[0].supply = "vddcx";
@@ -1906,7 +1903,7 @@ static int msm_otg_probe(struct platform_device *pdev)
ret = devm_regulator_bulk_get(motg->phy.dev, ARRAY_SIZE(regs), regs);
if (ret)
- goto unregister_extcon;
+ return ret;
motg->vddcx = regs[0].consumer;
motg->v3p3 = regs[1].consumer;
@@ -2003,11 +2000,6 @@ static int msm_otg_probe(struct platform_device *pdev)
clk_disable_unprepare(motg->clk);
if (!IS_ERR(motg->core_clk))
clk_disable_unprepare(motg->core_clk);
-unregister_extcon:
- extcon_unregister_notifier(motg->id.extcon,
- EXTCON_USB_HOST, &motg->id.nb);
- extcon_unregister_notifier(motg->vbus.extcon,
- EXTCON_USB, &motg->vbus.nb);
return ret;
}
@@ -2029,9 +2021,6 @@ static int msm_otg_remove(struct platform_device *pdev)
*/
gpiod_set_value_cansleep(motg->switch_gpio, 0);
- extcon_unregister_notifier(motg->id.extcon, EXTCON_USB_HOST,
&motg->id.nb);
- extcon_unregister_notifier(motg->vbus.extcon, EXTCON_USB,
&motg->vbus.nb);
-
msm_otg_debugfs_cleanup();
cancel_delayed_work_sync(&motg->chg_work);
cancel_work_sync(&motg->sm_work);
--
1.9.1
[PATCH 10/12] usb: phy: qcom-8x16-usb: Replace the extcon API
This patch uses the resource-managed extcon API for extcon_register_notifier() and replaces the deprecated extcon API as following: - extcon_get_cable_state_() -> extcon_get_state() Signed-off-by: Chanwoo Choi --- drivers/usb/phy/phy-qcom-8x16-usb.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c b/drivers/usb/phy/phy-qcom-8x16-usb.c index d8593adb3621..fdf686398772 100644 --- a/drivers/usb/phy/phy-qcom-8x16-usb.c +++ b/drivers/usb/phy/phy-qcom-8x16-usb.c @@ -187,7 +187,7 @@ static int phy_8x16_init(struct usb_phy *phy) val = ULPI_PWR_OTG_COMP_DISABLE; usb_phy_io_write(phy, val, ULPI_SET(ULPI_PWR_CLK_MNG_REG)); - state = extcon_get_cable_state_(qphy->vbus_edev, EXTCON_USB); + state = extcon_get_state(qphy->vbus_edev, EXTCON_USB); if (state) phy_8x16_vbus_on(qphy); else @@ -316,23 +316,20 @@ static int phy_8x16_probe(struct platform_device *pdev) goto off_clks; qphy->vbus_notify.notifier_call = phy_8x16_vbus_notify; - ret = extcon_register_notifier(qphy->vbus_edev, EXTCON_USB, - &qphy->vbus_notify); + ret = devm_extcon_register_notifier(&pdev->dev, qphy->vbus_edev, + EXTCON_USB, &qphy->vbus_notify); if (ret < 0) goto off_power; ret = usb_add_phy_dev(&qphy->phy); if (ret) - goto off_extcon; + goto off_power; qphy->reboot_notify.notifier_call = phy_8x16_reboot_notify; register_reboot_notifier(&qphy->reboot_notify); return 0; -off_extcon: - extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB, - &qphy->vbus_notify); off_power: regulator_bulk_disable(ARRAY_SIZE(qphy->regulator), qphy->regulator); off_clks: @@ -347,8 +344,6 @@ static int phy_8x16_remove(struct platform_device *pdev) struct phy_8x16 *qphy = platform_get_drvdata(pdev); unregister_reboot_notifier(&qphy->reboot_notify); - extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB, - &qphy->vbus_notify); /* * Ensure that D+/D- lines are routed to uB connector, so -- 1.9.1
[PATCH 03/12] power_supply: axp288_charger: Replace the extcon API
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/power/supply/axp288_charger.c | 51 +--
1 file changed, 13 insertions(+), 38 deletions(-)
diff --git a/drivers/power/supply/axp288_charger.c
b/drivers/power/supply/axp288_charger.c
index 75b8e0c7402b..1115052e9a69 100644
--- a/drivers/power/supply/axp288_charger.c
+++ b/drivers/power/supply/axp288_charger.c
@@ -581,15 +581,15 @@ static void axp288_charger_extcon_evt_worker(struct
work_struct *work)
bool old_connected = info->cable.connected;
/* Determine cable/charger type */
- if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_SDP) > 0) {
+ if (extcon_get_state(edev, EXTCON_CHG_USB_SDP) > 0) {
dev_dbg(&info->pdev->dev, "USB SDP charger is connected");
info->cable.connected = true;
info->cable.chg_type = POWER_SUPPLY_TYPE_USB;
- } else if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_CDP) > 0) {
+ } else if (extcon_get_state(edev, EXTCON_CHG_USB_CDP) > 0) {
dev_dbg(&info->pdev->dev, "USB CDP charger is connected");
info->cable.connected = true;
info->cable.chg_type = POWER_SUPPLY_TYPE_USB_CDP;
- } else if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_DCP) > 0) {
+ } else if (extcon_get_state(edev, EXTCON_CHG_USB_DCP) > 0) {
dev_dbg(&info->pdev->dev, "USB DCP charger is connected");
info->cable.connected = true;
info->cable.chg_type = POWER_SUPPLY_TYPE_USB_DCP;
@@ -686,7 +686,7 @@ static int axp288_charger_handle_otg_evt(struct
notifier_block *nb,
struct axp288_chrg_info *info =
container_of(nb, struct axp288_chrg_info, otg.id_nb);
struct extcon_dev *edev = info->otg.cable;
- int usb_host = extcon_get_cable_state_(edev, EXTCON_USB_HOST);
+ int usb_host = extcon_get_state(edev, EXTCON_USB_HOST);
dev_dbg(&info->pdev->dev, "external connector USB-Host is %s\n",
usb_host ? "attached" : "detached");
@@ -841,33 +841,27 @@ static int axp288_charger_probe(struct platform_device
*pdev)
/* Register for extcon notification */
INIT_WORK(&info->cable.work, axp288_charger_extcon_evt_worker);
info->cable.nb.notifier_call = axp288_charger_handle_cable_evt;
- ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_SDP,
- &info->cable.nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, info->cable.edev,
+ EXTCON_CHG_USB_SDP, &info->cable.nb);
if (ret) {
dev_err(&info->pdev->dev,
"failed to register extcon notifier for SDP %d\n", ret);
return ret;
}
- ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_CDP,
- &info->cable.nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, info->cable.edev,
+ EXTCON_CHG_USB_CDP, &info->cable.nb);
if (ret) {
dev_err(&info->pdev->dev,
"failed to register extcon notifier for CDP %d\n", ret);
- extcon_unregister_notifier(info->cable.edev,
- EXTCON_CHG_USB_SDP, &info->cable.nb);
return ret;
}
- ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_DCP,
- &info->cable.nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, info->cable.edev,
+ EXTCON_CHG_USB_DCP, &info->cable.nb);
if (ret) {
dev_err(&info->pdev->dev,
"failed to register extcon notifier for DCP %d\n", ret);
- extcon_unregister_notifier(info->cable.edev,
- EXTCON_CHG_USB_SDP, &info->cable.nb);
- extcon_unregister_notifier(info->cable.edev,
- EXTCON_CHG_USB_CDP, &info->cable.nb);
return ret;
}
@@ -887,13 +881,13 @@ static int axp288_charger_probe(struct platform_device
*pdev)
/* Register for OTG notification */
INIT_WORK(&info->otg.work, axp288_charger_otg_evt_worker);
info->otg.id_nb.notifier_call = axp288_charger_handle_otg_evt;
- ret = extcon_register_notifier(info->otg.cable, EXTCON_USB_HOST,
- &info->otg.id_nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, info->otg.cable,
+ EXTCON_USB_HOST, &info->otg.id_nb);
if (ret)
dev_warn(&pdev->dev, "failed to register otg notifier\n");
if (info->o
[PATCH 12/12] usb: renesas_usbhs: Replace the deprecated extcon API
This patch replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/renesas_usbhs/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 012a37aa3e0d..623c51300393 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -389,7 +389,7 @@ static void usbhsc_hotplug(struct usbhs_priv *priv)
if (enable && !mod) {
if (priv->edev) {
- cable = extcon_get_cable_state_(priv->edev,
EXTCON_USB_HOST);
+ cable = extcon_get_state(priv->edev, EXTCON_USB_HOST);
if ((cable > 0 && id != USBHS_HOST) ||
(!cable && id != USBHS_GADGET)) {
dev_info(&pdev->dev,
--
1.9.1
[PATCH 11/12] usb: phy: tahvo: Replace the deprecated extcon API
This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()
Signed-off-by: Chanwoo Choi
---
drivers/usb/phy/phy-tahvo.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
index 1343bff004eb..9a7822e12156 100644
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -121,7 +121,7 @@ static void check_vbus_state(struct tahvo_usb *tu)
prev_state = tu->vbus_state;
tu->vbus_state = reg & TAHVO_STAT_VBUS;
if (prev_state != tu->vbus_state) {
- extcon_set_cable_state_(tu->extcon, EXTCON_USB, tu->vbus_state);
+ extcon_set_state_sync(tu->extcon, EXTCON_USB, tu->vbus_state);
sysfs_notify(&tu->pt_dev->dev.kobj, NULL, "vbus_state");
}
}
@@ -130,7 +130,7 @@ static void tahvo_usb_become_host(struct tahvo_usb *tu)
{
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
- extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST, true);
+ extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST, true);
/* Power up the transceiver in USB host mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
@@ -149,7 +149,7 @@ static void tahvo_usb_become_peripheral(struct tahvo_usb
*tu)
{
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
- extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST, false);
+ extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST, false);
/* Power up transceiver and set it in USB peripheral mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_SLAVE_CONTROL | USBR_REGOUT |
@@ -379,9 +379,9 @@ static int tahvo_usb_probe(struct platform_device *pdev)
}
/* Set the initial cable state. */
- extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST,
+ extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST,
tu->tahvo_mode == TAHVO_MODE_HOST);
- extcon_set_cable_state_(tu->extcon, EXTCON_USB, tu->vbus_state);
+ extcon_set_state_sync(tu->extcon, EXTCON_USB, tu->vbus_state);
/* Create OTG interface */
tahvo_usb_power_off(tu);
--
1.9.1
Re: [PATCH v3 3/5] thermal: rockchip: fixes invalid temperature case
On Tue, Nov 29, 2016 at 09:02:42PM -0800, Eduardo Valentin wrote: > On Tue, Nov 29, 2016 at 01:57:45PM -0800, Brian Norris wrote: > > I was thinking while reviewing that the binary search serves more to > > complicate things than to help -- it's much harder to read (and validate > > that the loop termination logic is correct). And searching through a few > > dozen table entries doesn't really get much benefit from a O(n) -> > > O(log(n)) speed improvement. > > true. but if in your code path you do several walks in the table just to > check if parameters are valid, given that you could simply decide if > they are valid or not with simpler if condition, then, still worth, no? > :-) Yes, your suggestions seems like they would have made the code both (a little) more straightforward and efficient. But... > > Anyway, I'm not sure if you were thinking along the same lines as me. > > > > Something like that, except I though of something even simpler: > + if ((temp % table->step) != 0) > + return -ERANGE; > > If temp passes that check, then you go to the temp -> code conversion. ...that check isn't valid as of patch 4, where Caesar adds handling for intermediate steps. We really never should have been strictly snapping to the 5C steps in the first place; intermediate values are OK. So, we still need some kind of search to find the right step -- or closest bracketing range, to compute the interpolated value. We should only reject temperatures that are too high or too low for the ADC to represent. --- Side track --- BTW, when we're considering rejecting temperatures here: shouldn't this be fed back to the upper layers more nicely? We're improving the error handling for this driver in this series, but it still leaves things behaving a little odd. When I tested, I can do: ## set something obviously way too high echo 70 > trip_point_X_temp and get a 0 (success) return code from the sysfs write() syscall, even though the rockchip driver rejected it with -ERANGE. Is there really no way to feed back thermal range limits of a sensor to the of-thermal framework? Brian
[PATCH 07/12] usb: sunxi: Uses the resource-managed extcon API when registering extcon notifier
This patch just uses the resource-managed extcon API when registering the extcon notifier. Signed-off-by: Chanwoo Choi --- drivers/usb/musb/sunxi.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c index 1408245be18e..4b531551e49d 100644 --- a/drivers/usb/musb/sunxi.c +++ b/drivers/usb/musb/sunxi.c @@ -261,14 +261,14 @@ static int sunxi_musb_init(struct musb *musb) writeb(SUNXI_MUSB_VEND0_PIO_MODE, musb->mregs + SUNXI_MUSB_VEND0); /* Register notifier before calling phy_init() */ - ret = extcon_register_notifier(glue->extcon, EXTCON_USB_HOST, - &glue->host_nb); + ret = devm_extcon_register_notifier(glue->dev, glue->extcon, + EXTCON_USB_HOST, &glue->host_nb); if (ret) goto error_reset_assert; ret = phy_init(glue->phy); if (ret) - goto error_unregister_notifier; + goto error_reset_assert; musb->isr = sunxi_musb_interrupt; @@ -277,9 +277,6 @@ static int sunxi_musb_init(struct musb *musb) return 0; -error_unregister_notifier: - extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST, - &glue->host_nb); error_reset_assert: if (test_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags)) reset_control_assert(glue->rst); @@ -303,9 +300,6 @@ static int sunxi_musb_exit(struct musb *musb) phy_exit(glue->phy); - extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST, - &glue->host_nb); - if (test_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags)) reset_control_assert(glue->rst); -- 1.9.1
[PATCH 00/12] extcon: Replace the deprecated extcon API
This patches just replace the deprecated extcon API without any change of extcon operation and use the resource-managed function for extcon_register_notifier(). The new extcon API instead of deprecated API. - extcon_set_cable_state_() -> extcon_set_state_sync(); - extcon_get_cable_state_() -> extcon_get_state(); The each patch has not any dependency among patches. So, each maintainer could pick up each patch without any problem. Chanwoo Choi (12): phy: rcar-gen3-usb2: Replace the deprecated extcon API phy: sun4i-usb: Replace the deprecated extcon API power_supply: axp288_charger: Replace the extcon API power_supply: qcom_smbb: Replace the deprecated extcon API usb: chipdata: Replace the extcon API usb: dwc3: omap: Replace the extcon API usb: sunxi: Uses the resource-managed extcon API when registering extcon notifier usb: phy: msm: Replace the extcon API usb: phy: omap-otg: Replace the extcon API usb: phy: qcom-8x16-usb: Replace the extcon API usb: phy: tahvo: Replace the deprecated extcon API usb: renesas_usbhs: Replace the deprecated extcon API drivers/phy/phy-rcar-gen3-usb2.c | 8 +++--- drivers/phy/phy-sun4i-usb.c | 4 +-- drivers/power/supply/axp288_charger.c | 51 +-- drivers/power/supply/qcom_smbb.c | 2 +- drivers/usb/chipidea/core.c | 30 + drivers/usb/dwc3/dwc3-omap.c | 20 +- drivers/usb/musb/sunxi.c | 12 +++-- drivers/usb/phy/phy-msm-usb.c | 33 --- drivers/usb/phy/phy-omap-otg.c| 24 + drivers/usb/phy/phy-qcom-8x16-usb.c | 13 +++-- drivers/usb/phy/phy-tahvo.c | 10 +++ drivers/usb/renesas_usbhs/common.c| 2 +- 12 files changed, 63 insertions(+), 146 deletions(-) -- 1.9.1
[PATCH 05/12] usb: chipdata: Replace the extcon API
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/chipidea/core.c | 30 ++
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e644d17..a5b44963eaea 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -742,7 +742,7 @@ static int ci_get_platdata(struct device *dev,
cable->edev = ext_vbus;
if (!IS_ERR(ext_vbus)) {
- ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
+ ret = extcon_get_state(cable->edev, EXTCON_USB);
if (ret)
cable->state = true;
else
@@ -754,7 +754,7 @@ static int ci_get_platdata(struct device *dev,
cable->edev = ext_id;
if (!IS_ERR(ext_id)) {
- ret = extcon_get_cable_state_(cable->edev, EXTCON_USB_HOST);
+ ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
if (ret)
cable->state = false;
else
@@ -771,8 +771,8 @@ static int ci_extcon_register(struct ci_hdrc *ci)
id = &ci->platdata->id_extcon;
id->ci = ci;
if (!IS_ERR(id->edev)) {
- ret = extcon_register_notifier(id->edev, EXTCON_USB_HOST,
- &id->nb);
+ ret = devm_extcon_register_notifier(ci->dev, id->edev,
+ EXTCON_USB_HOST, &id->nb);
if (ret < 0) {
dev_err(ci->dev, "register ID failed\n");
return ret;
@@ -782,11 +782,9 @@ static int ci_extcon_register(struct ci_hdrc *ci)
vbus = &ci->platdata->vbus_extcon;
vbus->ci = ci;
if (!IS_ERR(vbus->edev)) {
- ret = extcon_register_notifier(vbus->edev, EXTCON_USB,
- &vbus->nb);
+ ret = devm_extcon_register_notifier(ci->dev, vbus->edev,
+ EXTCON_USB, &vbus->nb);
if (ret < 0) {
- extcon_unregister_notifier(id->edev, EXTCON_USB_HOST,
- &id->nb);
dev_err(ci->dev, "register VBUS failed\n");
return ret;
}
@@ -795,20 +793,6 @@ static int ci_extcon_register(struct ci_hdrc *ci)
return 0;
}
-static void ci_extcon_unregister(struct ci_hdrc *ci)
-{
- struct ci_hdrc_cable *cable;
-
- cable = &ci->platdata->id_extcon;
- if (!IS_ERR(cable->edev))
- extcon_unregister_notifier(cable->edev, EXTCON_USB_HOST,
- &cable->nb);
-
- cable = &ci->platdata->vbus_extcon;
- if (!IS_ERR(cable->edev))
- extcon_unregister_notifier(cable->edev, EXTCON_USB, &cable->nb);
-}
-
static DEFINE_IDA(ci_ida);
struct platform_device *ci_hdrc_add_device(struct device *dev,
@@ -1053,7 +1037,6 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (!ret)
return 0;
- ci_extcon_unregister(ci);
stop:
ci_role_destroy(ci);
deinit_phy:
@@ -1073,7 +1056,6 @@ static int ci_hdrc_remove(struct platform_device *pdev)
}
dbg_remove_files(ci);
- ci_extcon_unregister(ci);
ci_role_destroy(ci);
ci_hdrc_enter_lpm(ci, true);
ci_usb_phy_exit(ci);
--
1.9.1
[PATCH 01/12] phy: rcar-gen3-usb2: Replace the deprecated extcon API
This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()
Signed-off-by: Chanwoo Choi
---
drivers/phy/phy-rcar-gen3-usb2.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
index bd2430d7339c..7f8081f157f4 100644
--- a/drivers/phy/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/phy-rcar-gen3-usb2.c
@@ -93,11 +93,11 @@ static void rcar_gen3_phy_usb2_work(struct work_struct
*work)
work);
if (ch->extcon_host) {
- extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
- extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
+ extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, true);
+ extcon_set_state_sync(ch->extcon, EXTCON_USB, false);
} else {
- extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
- extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
+ extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, false);
+ extcon_set_state_sync(ch->extcon, EXTCON_USB, true);
}
}
--
1.9.1
[PATCH 04/12] power_supply: qcom_smbb: Replace the deprecated extcon API
This patch replaces the deprecated extcon API as following: - extcon_set_cable_state_() -> extcon_set_state_sync() Signed-off-by: Chanwoo Choi --- drivers/power/supply/qcom_smbb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/supply/qcom_smbb.c b/drivers/power/supply/qcom_smbb.c index bb91a1c339bc..7b1991265b03 100644 --- a/drivers/power/supply/qcom_smbb.c +++ b/drivers/power/supply/qcom_smbb.c @@ -378,7 +378,7 @@ static irqreturn_t smbb_usb_valid_handler(int irq, void *_data) struct smbb_charger *chg = _data; smbb_set_line_flag(chg, irq, STATUS_USBIN_VALID); - extcon_set_cable_state_(chg->edev, EXTCON_USB, + extcon_set_state_sync(chg->edev, EXTCON_USB, chg->status & STATUS_USBIN_VALID); power_supply_changed(chg->usb_psy); -- 1.9.1
[PATCH 09/12] usb: phy: omap-otg: Replace the extcon API
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi
---
drivers/usb/phy/phy-omap-otg.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
index 6523af4f8f93..800d1d90753d 100644
--- a/drivers/usb/phy/phy-omap-otg.c
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -118,19 +118,19 @@ static int omap_otg_probe(struct platform_device *pdev)
otg_dev->id_nb.notifier_call = omap_otg_id_notifier;
otg_dev->vbus_nb.notifier_call = omap_otg_vbus_notifier;
- ret = extcon_register_notifier(extcon, EXTCON_USB_HOST,
&otg_dev->id_nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, extcon,
+ EXTCON_USB_HOST, &otg_dev->id_nb);
if (ret)
return ret;
- ret = extcon_register_notifier(extcon, EXTCON_USB, &otg_dev->vbus_nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, extcon,
+ EXTCON_USB, &otg_dev->vbus_nb);
if (ret) {
- extcon_unregister_notifier(extcon, EXTCON_USB_HOST,
- &otg_dev->id_nb);
return ret;
}
- otg_dev->id = extcon_get_cable_state_(extcon, EXTCON_USB_HOST);
- otg_dev->vbus = extcon_get_cable_state_(extcon, EXTCON_USB);
+ otg_dev->id = extcon_get_state(extcon, EXTCON_USB_HOST);
+ otg_dev->vbus = extcon_get_state(extcon, EXTCON_USB);
omap_otg_set_mode(otg_dev);
rev = readl(otg_dev->base);
@@ -145,20 +145,8 @@ static int omap_otg_probe(struct platform_device *pdev)
return 0;
}
-static int omap_otg_remove(struct platform_device *pdev)
-{
- struct otg_device *otg_dev = platform_get_drvdata(pdev);
- struct extcon_dev *edev = otg_dev->extcon;
-
- extcon_unregister_notifier(edev, EXTCON_USB_HOST, &otg_dev->id_nb);
- extcon_unregister_notifier(edev, EXTCON_USB, &otg_dev->vbus_nb);
-
- return 0;
-}
-
static struct platform_driver omap_otg_driver = {
.probe = omap_otg_probe,
- .remove = omap_otg_remove,
.driver = {
.name = "omap_otg",
},
--
1.9.1
[PATCH 3/3] DT nodes for Broadcom Northstar2 USB DRD Phy
This patch adds device tree nodes for USB Dual Role Device Phy for
Broadcom's Northstar2 SoC.
Signed-off-by: Raviteja Garimella
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index d95dc40..e9d3496 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -299,6 +299,20 @@
};
};
+ usbdrd_phy: phy@66000960 {
+ #phy-cells = <0>;
+ compatible = "brcm,ns2-drd-phy";
+ reg = <0x66000960 0x24>,
+ <0x67012800 0x4>,
+ <0x6501d148 0x4>,
+ <0x664d0700 0x4>;
+ reg-names = "icfg", "rst-ctrl",
+ "crmu-ctrl", "usb2-strap";
+ id-gpios = <&gpio_g 30 0>;
+ vbus-gpios = <&gpio_g 31 0>;
+ status = "disabled";
+ };
+
pwm: pwm@6601 {
compatible = "brcm,iproc-pwm";
reg = <0x6601 0x28>;
--
2.1.0
[PATCH 0/3] Support for USB DRD Phy driver for NS2
This patch adds support for USB Dual Role Device Phy for Broadcom Northstar2 SoC. Apart from the new phy driver, this patchset contains changes to Kconfig, Makefile, and Device tree files. This patchset is tested on Broadcom NS2 BCM958712K reference board. Repo: https://github.com/Broadcom/arm64-linux.git Branch: ns2_drdphy Raviteja Garimella (3): Add DT bindings documentation for NS2 USB DRD phy Broadcom USB DRD Phy driver for Northstar2 DT nodes for Broadcom Northstar2 USB DRD Phy .../devicetree/bindings/phy/brcm,ns2-drd-phy.txt | 40 ++ arch/arm64/boot/dts/broadcom/ns2.dtsi | 14 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile | 1 + drivers/phy/phy-bcm-ns2-usbdrd.c | 587 + 5 files changed, 655 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt create mode 100644 drivers/phy/phy-bcm-ns2-usbdrd.c -- 2.1.0
[PATCH 1/3] Add DT bindings documentation for NS2 USB DRD phy
This patch adds documentation for NS2 DRD Phy driver DT bindings
Signed-off-by: Raviteja Garimella
---
.../devicetree/bindings/phy/brcm,ns2-drd-phy.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
new file mode 100644
index 000..5857f99
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
@@ -0,0 +1,40 @@
+BROADCOM NORTHSTAR2 USB2 (DUAL ROLE DEVICE) PHY
+
+Required properties:
+ - compatible: brcm,ns2-drd-phy
+ - reg: offset and length of the NS2 PHY related registers.
+ - reg-names
+ The below registers must be provided.
+ icfg - for DRD ICFG configurations
+ rst-ctrl - for DRD IDM reset
+ crmu-ctrl - for CRMU core vdd, PHY and PHY PLL reset
+ usb2-strap - for port over current polarity reversal
+ - #phy-cells: Must be 0. No args required.
+ - vbus-gpios: vbus gpio binding
+ - id-gpios: id gpio binding
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+ gpio_g: gpio@660a {
+ compatible = "brcm,iproc-gpio";
+ reg = <0x660a 0x50>;
+ ngpios = <32>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ interrupts = ;
+ };
+
+ usbdrd_phy: phy@66000960 {
+ #phy-cells = <0>;
+ compatible = "brcm,ns2-drd-phy";
+ reg = <0x66000960 0x24>,
+ <0x67012800 0x4>,
+ <0x6501d148 0x4>,
+ <0x664d0700 0x4>;
+ reg-names = "icfg", "rst-ctrl",
+ "crmu-ctrl", "usb2-strap";
+ id-gpios = <&gpio_g 30 0>;
+ vbus-gpios = <&gpio_g 31 0>;
+ };
--
2.1.0
[PATCH 2/3] Broadcom USB DRD Phy driver for Northstar2
This is driver for USB DRD Phy used in Broadcom's Northstar2
SoC. The phy can be configured to be in Device mode or Host
mode based on the type of cable connected to the port. The
driver registers to extcon framework to get appropriate
connect events for Host/Device cables connect/disconnect
states based on VBUS and ID interrupts.
Signed-off-by: Raviteja Garimella
---
drivers/phy/Kconfig | 13 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-bcm-ns2-usbdrd.c | 587 +++
3 files changed, 601 insertions(+)
create mode 100644 drivers/phy/phy-bcm-ns2-usbdrd.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index fe00f91..b3b6a73 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -479,6 +479,19 @@ config PHY_CYGNUS_PCIE
Enable this to support the Broadcom Cygnus PCIe PHY.
If unsure, say N.
+config PHY_NS2_USB_DRD
+ tristate "Broadcom Northstar2 USB DRD PHY support"
+ depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select GENERIC_PHY
+ select EXTCON
+ default ARCH_BCM_IPROC
+ help
+ Enable this to support the Broadcom Northstar2 USB DRD PHY.
+ This driver initializes the PHY in either HOST or DEVICE mode.
+ The host or device configuration is read from device tree.
+
+ If unsure, say N.
+
source "drivers/phy/tegra/Kconfig"
config PHY_NS2_PCIE
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a534cf5..b733ba2 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -58,5 +58,6 @@ obj-$(CONFIG_PHY_TUSB1210)+= phy-tusb1210.o
obj-$(CONFIG_PHY_BRCM_SATA)+= phy-brcm-sata.o
obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
+obj-$(CONFIG_PHY_NS2_USB_DRD) += phy-bcm-ns2-usbdrd.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
diff --git a/drivers/phy/phy-bcm-ns2-usbdrd.c b/drivers/phy/phy-bcm-ns2-usbdrd.c
new file mode 100644
index 000..460040d
--- /dev/null
+++ b/drivers/phy/phy-bcm-ns2-usbdrd.c
@@ -0,0 +1,587 @@
+/*
+ * Copyright (C) 2016 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ICFG_DRD_AFE 0x0
+#define ICFG_MISC_STAT 0x18
+#define ICFG_DRD_P0CTL 0x1C
+#define ICFG_STRAP_CTRL0x20
+#define ICFG_FSM_CTRL 0x24
+
+#define IDM_RST_BITBIT(0)
+#define AFE_CORERDY_VDDC BIT(18)
+#define PHY_PLL_RESETB BIT(15)
+#define PHY_RESETB BIT(14)
+#define PHY_PLL_LOCK BIT(0)
+
+#define DRD_DEV_MODE BIT(20)
+#define OHCI_OVRCUR_POLBIT(11)
+#define ICFG_OFF_MODE BIT(6)
+#define PLL_LOCK_RETRY 1000
+
+#define EVT_DEVICE 0
+#define EVT_HOST 1
+#define EVT_IDLE 2
+
+#define DRD_HOST_MODE (BIT(2) | BIT(3))
+#define DRD_DEVICE_MODE(BIT(4) | BIT(5))
+#define DRD_HOST_VAL 0x803
+#define DRD_DEV_VAL0x807
+#define GPIO_DELAY 20
+#define PHY_WQ_DELAY msecs_to_jiffies(600)
+
+struct ns2_phy_data;
+struct ns2_phy_driver {
+ void __iomem *icfgdrd_regs;
+ void __iomem *idmdrd_rst_ctrl;
+ void __iomem *crmu_usb2_ctrl;
+ void __iomem *usb2h_strap_reg;
+ spinlock_t lock; /* spin lock for phy driver */
+ bool host_mode;
+ struct ns2_phy_data *data;
+ struct extcon_specific_cable_nb extcon_dev;
+ struct extcon_specific_cable_nb extcon_host;
+ struct notifier_block host_nb;
+ struct notifier_block dev_nb;
+ struct delayed_work conn_work;
+ struct extcon_dev *edev;
+ struct gpio_desc *vbus_gpiod;
+ struct gpio_desc *id_gpiod;
+ int id_irq;
+ int vbus_irq;
+ unsigned long debounce_jiffies;
+ struct delayed_work wq_extcon;
+};
+
+struct ns2_phy_data {
+ struct ns2_phy_driver *driver;
+ struct phy *phy;
+ int new_state;
+ bool poweron;
+};
+
+static const unsigned int usb_extcon_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
+ EXTCON_NONE,
+};
+
+static inline int pll_lock_stat(u32 usb_reg, int reg_mask,
+ struct ns2_phy_driver *driver)
+{
+ in
Re: [kbuild-all] [PATCH 4/4] thermal/intel_powerclamp: stop sched tick in forced idle
On 11/28, Jacob Pan wrote: >On Tue, 29 Nov 2016 07:21:14 +0800 >kbuild test robot wrote: > >> Hi Jacob, >> >> [auto build test ERROR on soc-thermal/next] >> [also build test ERROR on v4.9-rc7 next-20161128] >> [if your patch is applied to the wrong git tree, please drop us a >> note to help improve the system] >> >This patchset is applicable on top of another patch indicated in the >cover letter. >(https://lkml.org/lkml/2016/11/28/683) > Thanks for the info, you could try use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on, then 0day would be able to know the exact base and prerequisite patches. Thanks, Xiaolong >Thanks, > >Jacob > >> url: >> https://github.com/0day-ci/linux/commits/Jacob-Pan/Misc-enhancements-to-intel_powerclamp/20161129-065523 >> base: >> https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git >> next config: x86_64-randconfig-x015-201648 (attached as .config) >> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the >> attached .config to linux build tree make ARCH=x86_64 >> >> All errors (new ones prefixed by >>): >> >>drivers/thermal/intel_powerclamp.c: In function >> 'clamp_idle_injection_func': >> >> drivers/thermal/intel_powerclamp.c:448:2: error: implicit >> >> declaration of function >> >> 'play_idle' [-Werror=implicit-function-declaration] >> play_idle(jiffies_to_msecs(w_data->duration_jiffies)); >> ^ >>cc1: some warnings being treated as errors >> >> vim +/play_idle +448 drivers/thermal/intel_powerclamp.c >> >>442 smp_mb(); >>443 } >>444 >>445 if (should_skip) >>446 goto balance; >>447 >> > 448 >> > play_idle(jiffies_to_msecs(w_data->duration_jiffies)); >>449 >>450 balance: >>451 if (clamping && w_data->clamping && >> cpu_online(w_data->cpu)) >> >> --- >> 0-DAY kernel test infrastructureOpen Source >> Technology Center >> https://lists.01.org/pipermail/kbuild-all Intel >> Corporation > >[Jacob Pan] >___ >kbuild-all mailing list >kbuild-...@lists.01.org >https://lists.01.org/mailman/listinfo/kbuild-all
Re: [lkp] [mm] e7c1db75fe: BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c
On 11/29, Paul E. McKenney wrote:
>On Tue, Nov 29, 2016 at 05:21:19PM +, Sudeep Holla wrote:
>> On Sun, Nov 27, 2016 at 6:16 PM, kernel test robot
>> wrote:
>> >
>> > FYI, we noticed the following commit:
>> >
>> > commit e7c1db75fed821a961ce1ca2b602b08e75de0cd8 ("mm: Prevent
>> > __alloc_pages_nodemask() RCU CPU stall warnings")
>> > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>> > rcu/next
>> >
>> > in testcase: boot
>> >
>> > on test machine: qemu-system-x86_64 -enable-kvm -cpu Nehalem -smp 2 -m 1G
>> >
>> > caused below changes:
>> >
>> [...]
>>
>> > [8.953192] BUG: sleeping function called from invalid context at
>> > mm/page_alloc.c:3746
>> > [8.956353] in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
>>
>> I am observing similar BUG/backtrace even on ARM64 platform.
>
>Does the (untested) patch below help?
>
> Thanx, Paul
Hi, Paul
I applied your patch on top of 2d66ccc "mm:
Prevent__alloc_pages_nodemask() RCU CPU stall warnings"(e7c1db7 turns to
2d66ccc in rcu/next branch now), here is the comparison of 6 times
testing, seems the BUG persists.
b70fa84d2eeef5f6be25633a2b is the commit id of commit "rcu: Allow
boot-time useof cond_resched_rcu_qs()"
testcase/path_params/tbox_group/run: boot/1/vm-vp-1G
2d66cccd73436ac9 b70fa84d2eeef5f6be25633a2b
--
6:60% 6:6
dmesg.BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c
Thanks,
Xiaolong
>
>
>
>commit ccc0666e2049e5818c236e647cf20c552a7b053b
>Author: Paul E. McKenney
>Date: Tue Nov 29 11:06:05 2016 -0800
>
>rcu: Allow boot-time use of cond_resched_rcu_qs()
>
>The cond_resched_rcu_qs() macro is used to force RCU quiescent states into
>long-running in-kernel loops. However, some of these loops can execute
>during early boot when interrupts are disabled, and during which time
>it is therefore illegal to enter the scheduler. This commit therefore
>makes cond_resched_rcu_qs() be a no-op during early boot.
>
>Signed-off-by: Paul E. McKenney
>
>diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
>index 525ca34603b7..8b4b1be8095b 100644
>--- a/include/linux/rcupdate.h
>+++ b/include/linux/rcupdate.h
>@@ -423,7 +423,7 @@ extern struct srcu_struct tasks_rcu_exit_srcu;
> */
> #define cond_resched_rcu_qs() \
> do { \
>- if (!cond_resched()) \
>+ if (rcu_scheduler_active && !cond_resched()) \
> rcu_note_voluntary_context_switch(current); \
> } while (0)
>
>
Re: [PATCH 19/39] mtd: nand: denali: perform erased check against raw transferred page
Hi Boris 2016-11-28 1:12 GMT+09:00 Boris Brezillon : > On Sun, 27 Nov 2016 03:06:05 +0900 > Masahiro Yamada wrote: > >> The erased page check must be done against the raw transferred data. >> The current first call of is_erase() is against the data after ECC >> correction. I saw cases where not all of the data in the page are >> 0xFF after they are manipulated by the ECC correction engine. > > Hm, that's surprising. Usually ECC engines leaves data unchanged when > uncorrectable errors are detected. Do you have examples where this > happens? How did you trigger this case? It always happens on some of my boards. At the bottom of this mail, I attached a dump of an erased page after it was manipulated by the ECC engine. See offset 0x2c1, 0x6c1 The data is 0xfd, not 0xff. I think basically two ways for erased page checking. [1] Read the whole of page + oob in raw mode transfer, then check if all the data are 0xFF. [2] Read the ECC-corrected page + oob, then check if *most* of the data are 0xFF. bit-flips less than ecc.strength are allowed. I think [2] is equivalent to calling nand_check_erased_ecc_chunk() with ecc.strength for threshold, as you suggested in 09/39 But, the current Denali driver does: [3] Read the ECC-corrected page + oob, then check if all the data are 0xFF. (no bit-flips are allowed) I think this is wrong because this erased page checking is false negative. This patches adopts [1] to solve my problem, but [2] will work as well. In my case, only one bit-flip (0xff -> 0xfd) in each ECC section. [ 19.194200]0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.200275] 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.206355] 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.212430] 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.218511] 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.224586] 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.230659] 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.236733] 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.242807] 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.248881] 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.254955] a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.261030] b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.267102] c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.273177] d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.279254] e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.285326] f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.291407] 100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.297481] 110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.303555] 120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.309630] 130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.315702] 140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.321778] 150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.327850] 160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.333927] 170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.340006] 180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.346082] 190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.352154] 1a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.358230] 1b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.364303] 1c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.370377] 1d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.376451] 1e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.382525] 1f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.388598] 200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.394674] 210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.400754] 220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.406829] 230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.412903] 240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.418977] 250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.425049] 260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.431124] 270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.437199] 280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.443274] 290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.449354] 2a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.455431] 2b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.461503] 2c0: ff fd ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.467578] 2d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.473651] 2e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.479727] 2f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.485812] 300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 19.491883] 310: ff ff ff ff ff ff ff ff
Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list
On 30-11-16, 07:06, Viresh Kumar wrote: > Okay, can you please send it formally and I can Ack it then ? I have sent it now to move things faster. Thanks. -- viresh
Re: [PATCH v2] perf sched timehist: Improve error message when analyzing wrong file
On 11/30/16, David Ahern wrote:
> Arnaldo reported an unhelpful error message when running perf sched
> timehist on a file that did not contain sched tracepoints:
>
> [root@jouet ~]# perf sched timehist
> No trace sample to read. Did you call 'perf record -R'?
>
> [root@jouet ~]# perf evlist -v
> cycles:ppp: size: 112, { sample_period, sample_freq }: 4000,
> sample_type: IP|TID|TIME|CALLCHAIN|CPU|PERIOD, disabled: 1, inherit: 1,
> mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1,
> exclude_guest: 1, mmap2: 1, comm_exec: 1
>
> Change the has_traces check to look for the sched_switch event. Analysis
> for perf sched timehist requires at least this event.
>
> Now when analyzing a file without sched tracepoints you get:
>
> root@f21-vbox:/tmp$ perf sched timehist
> No sched_switch events found. Have you run 'perf sched record'?
>
> Signed-off-by: David Ahern
Acked-by: Namhyung Kim
Thanks,
Namhyung
> ---
> tools/perf/builtin-sched.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
> index 870d94cd20ba..84c39f177bef 100644
> --- a/tools/perf/builtin-sched.c
> +++ b/tools/perf/builtin-sched.c
> @@ -2629,8 +2629,12 @@ static int perf_sched__timehist(struct perf_sched
> *sched)
> if (perf_session__set_tracepoints_handlers(session, handlers))
> goto out;
>
> - if (!perf_session__has_traces(session, "record -R"))
> + /* sched_switch event at a minimum needs to exist */
> + if (!perf_evlist__find_tracepoint_by_name(session->evlist,
> + "sched:sched_switch")) {
> + pr_err("No sched_switch events found. Have you run 'perf sched
> record'?\n");
> goto out;
> + }
>
> if (sched->show_migrations &&
> perf_session__set_tracepoints_handlers(session, migrate_handlers))
> --
> 2.7.4 (Apple Git-66)
>
>
--
Thanks,
Namhyung Kim
[PATCH v2] scripts: printing file name correctly
Currently we are printing file name wrongly.
pos->file ? (char *) pos->file : "")
It should be pos->file->name, and secondly if we got NULL
file struture,we will anyway derefer it in last printf.
So, Fixing the same.
caught with static analysis tool.
Signed-off-by: Maninder Singh
Signed-off-by: Vaneet Narang
---
v1 -> v2: changing description of patch.
scripts/dtc/srcpos.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/scripts/dtc/srcpos.c b/scripts/dtc/srcpos.c
index f534c22..360fd14 100644
--- a/scripts/dtc/srcpos.c
+++ b/scripts/dtc/srcpos.c
@@ -252,12 +252,11 @@ struct srcpos *
srcpos_dump(struct srcpos *pos)
{
printf("file: \"%s\"\n",
- pos->file ? (char *) pos->file : "");
+ pos->file ? pos->file->name : "");
printf("first_line : %d\n", pos->first_line);
printf("first_column: %d\n", pos->first_column);
printf("last_line : %d\n", pos->last_line);
printf("last_column : %d\n", pos->last_column);
- printf("file: %s\n", pos->file->name);
}
--
1.9.1
Re: [patch V2 00/12] thermal/x86_pkg_temp: Sanitize hotplug and locking
Rui, On Tue, Nov 22, 2016 at 05:57:04PM -, Thomas Gleixner wrote: > --- > x86_pkg_temp_thermal.c | 593 > - > 1 file changed, 249 insertions(+), 344 deletions(-) I am assuming you are handling this one in your tree directly. In any case, you can add my: Acked-by: Eduardo Valentin for the series. BR, Eduardo
Re: [PATCH v2 0/6] perf: Add option to specify time window of interest
Hi David and Arnaldo, On 11/30/16, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 29, 2016 at 10:15:40AM -0700, David Ahern escreveu: >> This series allows users to collect data and analyze a time window of >> interest within the file. >> >> v2 >> - renamed perf_time to perf_time_interval >> - changed ../perf.h to perf.h in patch 1 > > Thanks, applied and pushed out to acme/perf/core. If it's not too late: Acked-by: Namhyung Kim Thanks Namhyung >> David Ahern (6): >> perf tool: Add time-based utility functions >> perf tool: Move parse_nsec_time to time-utils.c >> perf script: Add option to specify time window of interest >> perf sched timehist: Add option to specify time window of interest >> perf kmem: Add option to specify time window of interest >> perf report: Add option to specify time window of interest >> >> tools/perf/Documentation/perf-kmem.txt | 7 ++ >> tools/perf/Documentation/perf-report.txt | 7 ++ >> tools/perf/Documentation/perf-sched.txt | 8 +++ >> tools/perf/Documentation/perf-script.txt | 7 ++ >> tools/perf/builtin-kmem.c| 24 +++ >> tools/perf/builtin-report.c | 14 +++- >> tools/perf/builtin-sched.c | 51 +++-- >> tools/perf/builtin-script.c | 15 +++- >> tools/perf/util/Build| 1 + >> tools/perf/util/time-utils.c | 118 >> +++ >> tools/perf/util/time-utils.h | 14 >> tools/perf/util/util.c | 33 - >> tools/perf/util/util.h | 2 - >> 13 files changed, 258 insertions(+), 43 deletions(-) >> create mode 100644 tools/perf/util/time-utils.c >> create mode 100644 tools/perf/util/time-utils.h >> >> -- >> 2.7.4 (Apple Git-66) > -- Thanks, Namhyung Kim
RE: [PATCH 6/9] bus: fsl-mc: dpio: add QBMan portal APIs for DPAA2
> -Original Message-
> From: Ruxandra Ioana Radulescu
> Sent: Monday, November 28, 2016 12:10 PM
> To: Stuart Yoder ; gre...@linuxfoundation.org
> Cc: German Rivera ; de...@driverdev.osuosl.org;
> linux-kernel@vger.kernel.org;
> ag...@suse.de; a...@arndb.de; Leo Li ; Roy Pledge
> ; Haiying Wang
>
> Subject: RE: [PATCH 6/9] bus: fsl-mc: dpio: add QBMan portal APIs for DPAA2
>
> > -Original Message-
> > From: Stuart Yoder [mailto:stuart.yo...@nxp.com]
> > Sent: Friday, October 21, 2016 9:02 AM
> > To: gre...@linuxfoundation.org
> > Cc: German Rivera ; de...@driverdev.osuosl.org;
> > linux-kernel@vger.kernel.org; ag...@suse.de; a...@arndb.de; Leo Li
> > ; Roy Pledge ; Roy Pledge
> > ; Haiying Wang ; Stuart
> > Yoder
> > Subject: [PATCH 6/9] bus: fsl-mc: dpio: add QBMan portal APIs for DPAA2
> >
> > From: Roy Pledge
> >
> > Add QBman APIs for frame queue and buffer pool operations.
> >
> > Signed-off-by: Roy Pledge
> > Signed-off-by: Haiying Wang
> > Signed-off-by: Stuart Yoder
> > ---
> > drivers/bus/fsl-mc/dpio/Makefile |2 +-
> > drivers/bus/fsl-mc/dpio/qbman-portal.c | 1009
> >
> > drivers/bus/fsl-mc/dpio/qbman-portal.h | 464 +++
> > 3 files changed, 1474 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/bus/fsl-mc/dpio/qbman-portal.c
> > create mode 100644 drivers/bus/fsl-mc/dpio/qbman-portal.h
> >
> > diff --git a/drivers/bus/fsl-mc/dpio/Makefile b/drivers/bus/fsl-
> > mc/dpio/Makefile
> > index 128befc..6588498 100644
> > --- a/drivers/bus/fsl-mc/dpio/Makefile
> > +++ b/drivers/bus/fsl-mc/dpio/Makefile
> > @@ -6,4 +6,4 @@ subdir-ccflags-y := -Werror
> >
> > obj-$(CONFIG_FSL_MC_DPIO) += fsl-mc-dpio.o
> >
> > -fsl-mc-dpio-objs := dpio.o
> > +fsl-mc-dpio-objs := dpio.o qbman-portal.o
> > diff --git a/drivers/bus/fsl-mc/dpio/qbman-portal.c b/drivers/bus/fsl-
> > mc/dpio/qbman-portal.c
> > new file mode 100644
> > index 000..1eb3dd9
> > --- /dev/null
> > +++ b/drivers/bus/fsl-mc/dpio/qbman-portal.c
>
> [...]
>
> > +/**
> > + * qbman_swp_pull() - Issue the pull dequeue command
> > + * @s: the software portal object
> > + * @d: the software portal descriptor which has been configured with
> > + * the set of qbman_pull_desc_set_*() calls
> > + *
> > + * Return 0 for success, and -EBUSY if the software portal is not ready
> > + * to do pull dequeue.
> > + */
> > +int qbman_swp_pull(struct qbman_swp *s, struct qbman_pull_desc *d)
> > +{
> > + struct qbman_pull_desc *p;
> > +
> > + if (!atomic_dec_and_test(&s->vdq.available)) {
> > + atomic_inc(&s->vdq.available);
> > + return -EBUSY;
> > + }
> > + s->vdq.storage = (void *)d->rsp_addr_virt;
> > + d->tok = 1;
> > + p = qbman_get_cmd(s, QBMAN_CENA_SWP_VDQCR);
> > + *p = *d;
> > + dma_wmb();
> > +
> > + /* Set the verb byte, have to substitute in the valid-bit */
> > + p->verb |= s->vdq.valid_bit;
> > + s->vdq.valid_bit ^= QB_VALID_BIT;
> > +
> > + return 0;
> > +}
> > +
> [...]
> > +
> > +/**
> > + * qbman_result_has_new_result() - Check and get the dequeue response
> > from the
> > + * dq storage memory set in pull dequeue
> > command
> > + * @s: the software portal object
> > + * @dq: the dequeue result read from the memory
> > + *
> > + * Return 1 for getting a valid dequeue result, or 0 for not getting a
> > valid
> > + * dequeue result.
> > + *
> > + * Only used for user-provided storage of dequeue results, not DQRR. For
> > + * efficiency purposes, the driver will perform any required endianness
> > + * conversion to ensure that the user's dequeue result storage is in host-
> > endian
> > + * format. As such, once the user has called
> > qbman_result_has_new_result() and
> > + * been returned a valid dequeue result, they should not call it again on
> > + * the same memory location (except of course if another dequeue
> > command has
> > + * been executed to produce a new result to that location).
> > + */
> > +int qbman_result_has_new_result(struct qbman_swp *s, const struct
> > dpaa2_dq *dq)
> > +{
> > + if (!dq->dq.tok)
> > + return 0;
>
> While testing the Ethernet driver I discovered that sometimes the above
> check fails.
>
> When we check a store entry for the first time, if the hardware didn't
> manage to fill it with a valid respose yet, we may find a non-null value in
> the
> token field (because the stores have uninitialized memory). So by only
> checking that token is !=0, we risk processing an uninitialized memory area
> as a valid dequeue entry.
>
> We should always compare the token field against 1, the value that is given
> to the hardware on the dequeue command. It might also be a good idea
> to use a define here, to make it clear 1 is a magic value.
>
> And I think we should also zero the stores when they are first allocated,
> since even with the proposed fix there's still a (much smaller) risk of
> finding
> our exact token value in an unin
Re: [PATCH 2/2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries
On 30/11/16 04:24, Alex Thorlton wrote: > On systems with sufficiently large e820 tables, and several IOAPICs, it > is possible for the XENMEM_machine_memory_map callback (and its > counterpart, XENMEM_memory_map) to attempt to return an e820 table with > more than 128 entries. This callback adds entries to the BIOS-provided > e820 table to account for IOAPIC registers, which, on sufficiently large > systems, can result in an e820 table that is too large to copy back into > xen_e820_map. > > This change simply increases the size of xen_e820_map to E820_X_MAX to > ensure that there is enough room to store the entire e820 map returned > from this callback. > > Signed-off-by: Alex Thorlton > Suggested-by: Boris Ostrovsky Reviewed-by: Juergen Gross Juergen > Cc: Russ Anderson > Cc: David Vrabel > Cc: Ingo Molnar > Cc: Juergen Gross > Cc: Thomas Gleixner > Cc: "H. Peter Anvin" > Cc: Denys Vlasenko > Cc: Boris Ostrovsky > Cc: x...@kernel.org > Cc: xen-de...@lists.xenproject.org > --- > arch/x86/xen/setup.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index f8960fc..8c394e3 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -41,7 +41,7 @@ > unsigned long xen_released_pages; > > /* E820 map used during setting up memory. */ > -static struct e820entry xen_e820_map[E820MAX] __initdata; > +static struct e820entry xen_e820_map[E820_X_MAX] __initdata; > static u32 xen_e820_map_entries __initdata; > > /* > @@ -750,7 +750,7 @@ char * __init xen_memory_setup(void) > max_pfn = min(max_pfn, xen_start_info->nr_pages); > mem_end = PFN_PHYS(max_pfn); > > - memmap.nr_entries = E820MAX; > + memmap.nr_entries = ARRAY_SIZE(xen_e820_map); > set_xen_guest_handle(memmap.buffer, xen_e820_map); > > op = xen_initial_domain() ? > @@ -923,7 +923,7 @@ char * __init xen_auto_xlated_memory_setup(void) > int i; > int rc; > > - memmap.nr_entries = E820MAX; > + memmap.nr_entries = ARRAY_SIZE(xen_e820_map); > set_xen_guest_handle(memmap.buffer, xen_e820_map); > > rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap); >
[PATCH net 1/2] tun: handle ubuf refcount correctly when meet erros
We trigger uarg->callback() immediately after we decide do datacopy
even if caller want to do zerocopy. This will cause the callback
(vhost_net_zerocopy_callback) decrease the refcount. But when we meet
an error afterwards, the error handling in vhost handle_tx() will try
to decrease it again. This is wrong and fix this by delay the
uarg->callback() until we're sure there's no errors.
Reported-by: wangyunjian
Signed-off-by: Jason Wang
---
The patch is needed for -stable.
---
drivers/net/tun.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8093e39..db6acec 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1246,13 +1246,8 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
if (zerocopy)
err = zerocopy_sg_from_iter(skb, from);
- else {
+ else
err = skb_copy_datagram_from_iter(skb, 0, from, len);
- if (!err && msg_control) {
- struct ubuf_info *uarg = msg_control;
- uarg->callback(uarg, false);
- }
- }
if (err) {
this_cpu_inc(tun->pcpu_stats->rx_dropped);
@@ -1298,6 +1293,9 @@ static ssize_t tun_get_user(struct tun_struct *tun,
struct tun_file *tfile,
skb_shinfo(skb)->destructor_arg = msg_control;
skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY;
skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG;
+ } else if (msg_control) {
+ struct ubuf_info *uarg = msg_control;
+ uarg->callback(uarg, false);
}
skb_reset_network_header(skb);
--
2.7.4
[PATCH net 2/2] macvtap: handle ubuf refcount correctly when meet erros
We trigger uarg->callback() immediately after we decide do datacopy
even if caller want to do zerocopy. This will cause the callback
(vhost_net_zerocopy_callback) decrease the refcount. But when we meet
an error afterwards, the error handling in vhost handle_tx() will try
to decrease it again. This is wrong and fix this by delay the
uarg->callback() until we're sure there's no errors.
Signed-off-by: Jason Wang
---
The patch is needed for -stable.
---
drivers/net/macvtap.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index bceca28..7869b06 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -742,13 +742,8 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q,
struct msghdr *m,
if (zerocopy)
err = zerocopy_sg_from_iter(skb, from);
- else {
+ else
err = skb_copy_datagram_from_iter(skb, 0, from, len);
- if (!err && m && m->msg_control) {
- struct ubuf_info *uarg = m->msg_control;
- uarg->callback(uarg, false);
- }
- }
if (err)
goto err_kfree;
@@ -779,7 +774,11 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q,
struct msghdr *m,
skb_shinfo(skb)->destructor_arg = m->msg_control;
skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY;
skb_shinfo(skb)->tx_flags |= SKBTX_SHARED_FRAG;
+ } else if (m && m->msg_control) {
+ struct ubuf_info *uarg = m->msg_control;
+ uarg->callback(uarg, false);
}
+
if (vlan) {
skb->dev = vlan->dev;
dev_queue_xmit(skb);
--
2.7.4
RE: [PATCH][V2] scsi: megaraid-sas: fix spelling mistake of "outstanding"
> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@sandisk.com] > Sent: Wednesday, November 30, 2016 12:50 AM > To: Colin King; Kashyap Desai; Sumit Saxena; Shivasharan S; James E . J . > Bottomley; Martin K . Petersen; megaraidlinux@broadcom.com; linux- > s...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Subject: Re: [PATCH][V2] scsi: megaraid-sas: fix spelling mistake of > "outstanding" > > On 11/29/2016 11:13 AM, Colin King wrote: > > Trivial fix to spelling mistake "oustanding" to "outstanding" in > > dev_info and scmd_printk messages. Also join wrapped literal string in > > the scmd_printk. > > Reviewed-by: Bart Van Assche Please hold this commit as we have patch set work in progress for MegaRaid Driver. It will conflict it this patch commits. We will be re-submitting this patch with appropriate Signed-off and Submitted-by tags. Thanks, Kashyap
Re: [PATCH v3 1/5] thermal: rockchip: improve conversion error messages
Hey, On Mon, Nov 28, 2016 at 09:47:29PM -0800, Brian Norris wrote: > Hi, > > > > +__func__, table.mode); > > > > Given that we are improving messages, would it be more informative to > > say that you have an invalid table mode? > > I considered the mode and ID listing to go hand in hand, so it was the > whole table that is wrong. But it is just as well to say the "table > mode" is wrong. > > Maybe even better: "%s: unknown table mode: %d\n". > Yup, that works for me, even better. > And I guess same answer for patch 4, where you had the same question. yes > > Brian > > > > + return -EINVAL;
Re: [PATCH v3 3/5] thermal: rockchip: fixes invalid temperature case
Hey Brian, On Tue, Nov 29, 2016 at 01:57:45PM -0800, Brian Norris wrote: > Hi Eduardo, > > I'm not sure I completely understand what you're asking, but I'll see > what I can answer. > > On Mon, Nov 28, 2016 at 05:45:54PM -0800, Eduardo Valentin wrote: > > On Mon, Nov 28, 2016 at 07:12:02PM +0800, Caesar Wang wrote: > > > The temp_to_code function will return 0 when we set the temperature to a > > > invalid value (e.g. 61C, 62C, 63C), that's unpractical. This patch > > > will prevent this case happening. That will return the max analog value to > > > indicate the temperature is invalid or over table temperature range. > > > > > > > > > > > > /* Make sure the value is valid */ > > > alarm_value = rk_tsadcv2_temp_to_code(table, temp); > > > > dummy question here, looking at your tables, if I did not miss > > something, looks like we have an accuracy of 5C steps. Not only, that, > > we also support only multiples of 5C temperatures. If that observation > > Currently, that's true I think. But patch 4 actually supports doing the > linear interpolation that is claimed (but not fully implemented) in the > comments today. So with that patch, we roughly support temperatures in > between the 5C intervals. > > > is correct, would it make more sense to simply check for this property, > > I'm not quite sure what you mean by "this property." Do you mean to just > assume that there will be 5C intervals, and jump ahead in the table > accordingly? Seems a bit fragile; nothing really guarantees that a > future ADC supported by this driver won't have 1, 2, 6, or 7C accuracy > (and therefore a different set of steps). I was thinking something even simpler. I just thought that you could avoid going into the binary search on the temp to code function by simply checking if the temperature in the temp parameter is a multiple of the table step. I agree that might be a bit of a strong assumption, but then again, one should avoid over engineering for future hardware, unless you already know that the coming ADC versions will have different steps, or even worse, no step pattern at all. > > > and min and max temperature check, instead of going through the binary > > search to check for valid temperature? > > I was thinking while reviewing that the binary search serves more to > complicate things than to help -- it's much harder to read (and validate > that the loop termination logic is correct). And searching through a few > dozen table entries doesn't really get much benefit from a O(n) -> > O(log(n)) speed improvement. true. but if in your code path you do several walks in the table just to check if parameters are valid, given that you could simply decide if they are valid or not with simpler if condition, then, still worth, no? :-) > > Anyway, I'm not sure if you were thinking along the same lines as me. > Something like that, except I though of something even simpler: + if ((temp % table->step) != 0) + return -ERANGE; If temp passes that check, then you go to the temp -> code conversion. > Brian
Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64
On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote: > This series enables aarch64 with ilp32 mode, and as supporting work, > introduces ARCH_32BIT_OFF_T configuration option that is enabled for > existing 32-bit architectures but disabled for new arches (so 64-bit > off_t is is used by new userspace). > > This version is based on kernel v4.9-rc1. It works with glibc-2.24, > and tested with LTP. > > This version contains ABI changes, and should be used with new glibc > version. See links below. > > This is RFC because there is still no solid understanding what type > of registers top-halves delousing we prefer and it affects ABI. In > this patchset, w0-w7 are cleared for each syscall in assembler entry. > > The alternative approach is in introducing compat wrappers which is > little faster for natively routed syscalls (~2.6% for syscall with > no payload) but much more complicated. Hi all, Steve Ellcey submitted glibc patches for ILP32: https://www.sourceware.org/ml/libc-alpha/2016-11/msg01071.html It implicitly assumes that kernel clears top halves of registers for all syscalls in assembly entry. That patches are going to be taken. It it happens, we will have no choice on kernel side how to clear top halves anymore. For me current version is OK, and I see no problems with it. I just write this email to remind that it's still RFC, and this is the last chance to get back to wrappers. Yury.
Re: [PATCH v11 0/8] powerpc: Implement kexec_file_load()
Andrew Morton writes: > On Tue, 29 Nov 2016 23:45:46 +1100 Michael Ellerman > wrote: > >> This is v11 of the kexec_file_load() for powerpc series. >> >> I've stripped this down to the minimum we need, so we can get this in for >> 4.10. >> Any additions can come later incrementally. > > This made a bit of a mess of Mimi's series "ima: carry the > measurement list across kexec v10". Urk, sorry about that. I didn't realise there was a big dependency between them, but I guess I should have tried to do the rebase. > powerpc-ima-get-the-kexec-buffer-passed-by-the-previous-kernel.patch > ima-on-soft-reboot-restore-the-measurement-list.patch > ima-permit-duplicate-measurement-list-entries.patch > ima-maintain-memory-size-needed-for-serializing-the-measurement-list.patch > powerpc-ima-send-the-kexec-buffer-to-the-next-kernel.patch > ima-on-soft-reboot-save-the-measurement-list.patch > ima-store-the-builtin-custom-template-definitions-in-a-list.patch > ima-support-restoring-multiple-template-formats.patch > ima-define-a-canonical-binary_runtime_measurements-list-format.patch > ima-platform-independent-hash-value.patch > > I made the syntactic fixes but I won't be testing it. Thanks. TBH I don't know how to test the IMA part, I'm relying on Thiago and Mimi to do that. >> If no one objects I'll merge this via the powerpc tree. The three kexec >> patches >> have been acked by Dave Young (since forever), and have been in linux-next >> (via >> akpm's tree) also for a long time. > > OK, I'll wait for these to appear in -next and I will await advice on Thanks. I'll let them stew for a few more hours and then put them in my next for tomorrows linux-next. cheers
Re: netlink: GPF in sock_sndtimeo
On 2016-11-29 15:13, Cong Wang wrote: > On Tue, Nov 29, 2016 at 8:48 AM, Richard Guy Briggs wrote: > > On 2016-11-26 17:11, Cong Wang wrote: > >> It is racy on audit_sock, especially on the netns exit path. > > > > I think that is the only place it is racy. The other places audit_sock > > is set is when the socket failure has just triggered a reset. > > > > Is there a notifier callback for failed or reaped sockets? > > Is NETLINK_URELEASE event what you are looking for? Possibly, yes. Thanks, I'll have a look. - RGB -- Richard Guy Briggs Kernel Security Engineering, Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635
[PATCH v2] arm64: dts: exynos: Add flash led dt node for TM2 board
From: Ingi Kim
This patch adds Kinetic ktd2692 flash led device node for TM2 board.
Signed-off-by: Ingi Kim
Signed-off-by: Seung-Woo Kim
---
Change from v1:
- gpio active value is set with defined macro instead of value.
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index f21bdc2..0d454aa 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -58,6 +58,19 @@
reg = <0x0 0x2000 0x0 0xc000>;
};
+ camera-flash {
+ compatible = "kinetic,ktd2692";
+ ctrl-gpios = <&gpc0 1 GPIO_ACTIVE_HIGH>;
+ aux-gpios = <&gpc0 2 GPIO_ACTIVE_HIGH>;
+
+ flash-led {
+ label = "ktd2692-flash";
+ led-max-microamp = <30>;
+ flash-max-microamp = <150>;
+ flash-max-timeout-us = <1835000>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
--
1.7.4.1
Re: [PATCH] audit: remove the audit freelist
On 2016-11-29 18:24, Florian Westphal wrote:
> Richard Guy Briggs wrote:
> > > static void audit_buffer_free(struct audit_buffer *ab)
> > > {
> > > - unsigned long flags;
> > > -
> > > if (!ab)
> > > return;
> > >
> > > kfree_skb(ab->skb);
> > > - spin_lock_irqsave(&audit_freelist_lock, flags);
> > > - if (audit_freelist_count > AUDIT_MAXFREE)
> > > - kfree(ab);
> > > - else {
> > > - audit_freelist_count++;
> > > - list_add(&ab->list, &audit_freelist);
> > > - }
> > > - spin_unlock_irqrestore(&audit_freelist_lock, flags);
> > > + kfree(ab);
> > > }
> [..]
>
> > > nlh = nlmsg_put(ab->skb, 0, 0, type, 0, 0);
> > > if (!nlh)
> > > - goto out_kfree_skb;
> > > + goto err;
> > >
> > > return ab;
> > >
> > > -out_kfree_skb:
> > > - kfree_skb(ab->skb);
> > > - ab->skb = NULL;
> >
> > Why is the kfree_skb() skipped on error from nlmsg_put()? I don't see
> > much risk in nlmsg_put() failing considering the very simple arguments,
> > however the code path is not trivial either.
>
> if nlmsg_put fails we jump to err and ...
>
> > > err:
> > > audit_buffer_free(ab);
> > > return NULL;
>
> ... ab->skb gets free'd by audit_buffer_free() here.
Duh, thank you! It was already redundant in plain sight in your patch.
Sorry for the brain fart. :)
Reviewed-by: Richard Guy Briggs
- RGB
--
Richard Guy Briggs
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
Re: [RFC][PATCH 5/5 v2] drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID
On 11/29/2016 10:34 AM, John Stultz wrote:
I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors
on HiKey.
Investigating further, it seems some of the register state
in the regmap cache is somehow getting lost. Using the logic
in __adv7511_power_on/off() which syncs and dirtys the cache
avoids this issue.
Thus this patch changes the EDID probing logic so that we
re-use the __adv7511_power_on/off() calls.
Cc: David Airlie
Cc: Archit Taneja
Cc: Wolfram Sang
Cc: Lars-Peter Clausen
Cc: Laurent Pinchart
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2: Split into two patches to make the change more clear.
Also provided more rational as to why the change is
important.
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 1948968..487b33d 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -559,24 +559,13 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
unsigned int count;
/* Reading the EDID only works if the device is powered */
- if (!adv7511->powered) {
- regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
- ADV7511_POWER_POWER_DOWN, 0);
- if (adv7511->i2c_main->irq) {
- regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
-ADV7511_INT0_EDID_READY);
- regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
-ADV7511_INT1_DDC_ERROR);
- }
- adv7511->current_edid_segment = -1;
- }
+ if (!adv7511->powered)
+ __adv7511_power_on(adv7511);
In terms of changes in terms of register configurations, replacing with
__adv7511_power_on() here would add a register write to ADV7511_REG_POWER2
as discussed before.
Also, after the patch that enables HPD, we'd also be adding the ADV7511_INT0_HPD
bit in ADV7511_REG_INT_ENABLE(0).
I am not entirely sure about what effect adding POWER2 would have. If we don't
see any negative effects because of it, I think we should be fine.
The extra HPD bit in INT_ENABLE(0) shouldn't be a problem, though. In fact, it
prevents the HPD mask from being cleared after we get_modes is called, which may
have resulted in us missing out on HPD interrupts.
Thanks,
Archit
edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
if (!adv7511->powered)
- regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
- ADV7511_POWER_POWER_DOWN,
- ADV7511_POWER_POWER_DOWN);
+ __adv7511_power_off(adv7511);
kfree(adv7511->edid);
adv7511->edid = edid;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: next: Commit 'mm: Prevent __alloc_pages_nodemask() RCU CPU stall ...' causing hang on sparc32 qemu
On 11/29/2016 05:28 PM, Paul E. McKenney wrote:
On Tue, Nov 29, 2016 at 01:23:08PM -0800, Guenter Roeck wrote:
Hi Paul,
most of my qemu tests for sparc32 targets started to fail in next-20161129.
The problem is only seen in SMP builds; non-SMP builds are fine.
Bisect points to commit 2d66cccd73436 ("mm: Prevent __alloc_pages_nodemask()
RCU CPU stall warnings"); reverting that commit fixes the problem.
Test scripts are available at:
https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc
Test results are at:
https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc
Bisect log is attached.
Please let me know if there is anything I can do to help tracking down the
problem.
Apologies!!! Does the patch below help?
No, sorry, it doesn't make a difference.
Guenter
Thanx, Paul
commit 97708e737e2a55fed4bdbc005bf05ea909df6b73
Author: Paul E. McKenney
Date: Tue Nov 29 11:06:05 2016 -0800
rcu: Allow boot-time use of cond_resched_rcu_qs()
The cond_resched_rcu_qs() macro is used to force RCU quiescent states into
long-running in-kernel loops. However, some of these loops can execute
during early boot when interrupts are disabled, and during which time
it is therefore illegal to enter the scheduler. This commit therefore
makes cond_resched_rcu_qs() be a no-op during early boot.
Signed-off-by: Paul E. McKenney
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 525ca34603b7..b6944cc19a07 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -423,7 +423,7 @@ extern struct srcu_struct tasks_rcu_exit_srcu;
*/
#define cond_resched_rcu_qs() \
do { \
- if (!cond_resched()) \
+ if (!is_idle_task(current) && !cond_resched()) \
rcu_note_voluntary_context_switch(current); \
} while (0)
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index 7232d199a81c..20f5990d 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -228,6 +228,7 @@ static inline void exit_rcu(void)
extern int rcu_scheduler_active __read_mostly;
void rcu_scheduler_starting(void);
#else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
+#define rcu_scheduler_active false
static inline void rcu_scheduler_starting(void)
{
}
[PATCH] Staging: wlan-ng: hfa384x_usb.c Fixed too long code line warnings.
Fixed checkpatch warning "line over 80 characters" in
wlan-ng/hfa384x_usb.c file.
Signed-off-by: Yan Laijun
---
drivers/staging/wlan-ng/hfa384x_usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 5f11f6e..3447fc5 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3037,7 +3037,7 @@ static void hfa384x_usbin_callback(struct urb *urb)
{
struct wlandevice *wlandev = urb->context;
struct hfa384x *hw;
- union hfa384x_usbin *usbin = (union hfa384x_usbin
*)urb->transfer_buffer;
+ union hfa384x_usbin *usbin = NULL;
struct sk_buff *skb = NULL;
int result;
int urb_status;
@@ -3049,6 +3049,7 @@ static void hfa384x_usbin_callback(struct urb *urb)
ABORT
} action;
+ usbin = (union hfa384x_usbin *)urb->transfer_buffer;
if (!wlandev || !wlandev->netdev || wlandev->hwremoved)
goto exit;
--
1.9.1
[PATCH] arm64: dts: exynos: Add flash led dt node for TM2 board
From: Ingi Kim
This patch adds Kinetic ktd2692 flash led device node for TM2 board.
Signed-off-by: Ingi Kim
Signed-off-by: Seung-Woo Kim
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index f21bdc2..3ba305f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -58,6 +58,19 @@
reg = <0x0 0x2000 0x0 0xc000>;
};
+ camera-flash {
+ compatible = "kinetic,ktd2692";
+ ctrl-gpios = <&gpc0 1 0>;
+ aux-gpios = <&gpc0 2 0>;
+
+ flash-led {
+ label = "ktd2692-flash";
+ led-max-microamp = <30>;
+ flash-max-microamp = <150>;
+ flash-max-timeout-us = <1835000>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
--
1.7.4.1
Re: [PATCH] net: macb: Write only necessary bits in NCR in macb reset
Hi David, On Wed, Nov 30, 2016 at 5:35 AM, David Miller wrote: > From: Harini Katakam > Date: Mon, 28 Nov 2016 14:53:49 +0530 > >> In macb_reset_hw, use read-modify-write to disable RX and TX. >> This way exiting settings and reserved bits wont be disturbed. >> Use the same method for clearing statistics as well. >> >> Signed-off-by: Harini Katakam > > This doesn't make much sense to me. > > Consider the two callers of this function. > > macb_init_hw() is going to do a non-masking write to the NCR > register: > > /* Enable TX and RX */ > macb_writel(bp, NCR, MACB_BIT(RE) | MACB_BIT(TE) | MACB_BIT(MPE)); > > So obviously no other writable fields matter at all for programming > the chip properly, otherwise macb_init_hw() would "or" in the bits > after a read of NCR. But that's not what this code does, it > writes "RE | TE | MPE" directly. > > And the other caller is macb_close() which is shutting down the > chip so can zero out all the other bits and it can't possibly > matter, also due to the assertion above about macb_init_hw() > showing that only the RE, TE, and MPE bits matter for proper > functioning of the chip. > > You haven't shown a issue caused by the way the code works now, so > this patch isn't fixing a bug. In fact, the "bit preserving" would > even be misleading to someone reading the code. They will ask > themselves what bits need to be preserved, and as shown above none of > them need to be. > > I'm not applying this, sorry. > Thanks for the detailed analysis. I noticed an issue with respect to management port enable bit when working on the patch series for macb mdio driver for multi MAC - multi PHY access via same mdio bus. MPE bit of the MAC (whose phy management register is used) was being reset. But that is a separate series still in review. You are right, there is no existing bug that this patch addresses. I will come back to this later if required. Regards, Harini
Re: [PATCH net 00/16] net: fix fixed-link phydev leaks
From: Johan Hovold Date: Mon, 28 Nov 2016 19:24:53 +0100 > This series fixes failures to deregister and free fixed-link phydevs > that have been registered using the of_phy_register_fixed_link() > interface. > > All but two drivers currently fail to do this and this series fixes most > of them with the exception of a staging driver and the stmmac drivers > which will be fixed by follow-on patches. > > Included are also a couple of fixes for related of-node leaks. > > Note that all patches except the of_mdio one have been compile-tested > only. > > Also note that the series is against net due to dependencies not yet in > net-next. Series applied, thanks Johan.
Re: linker-tables v5 testing
On 11/29/2016 05:33 PM, Luis R. Rodriguez wrote: On Thu, Nov 24, 2016 at 08:18:40AM -0800, Guenter Roeck wrote: Hi Luis, On 11/23/2016 08:11 PM, Luis R. Rodriguez wrote: Guenter, I think I'm ready to start pushing a new patch set out for review. Before I do that -- can I trouble you for letting your test infrastructure hammer it? I'll only push out the patches for review based on this new set of changes once all tests come back OK for all architectures. https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20161117-linker-tables-v5 Fenguang & Guenter, Any chance I can trouble you to enable the new driver: CONFIG_TEST_LINKTABLES=y on each kernel configuration as it will run a test driver which will WARN_ON() if it finds any errors. I see a number of compile failures as well as some crashes in your test driver. Please have a look. http://kerneltests.org/builders, column 'testing'. Thanks! I believe I have addressed most issues.. Any chance I can have you re-try with this new branch: https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20161117-linker-tables-v5-try2 Pushed ... should start shortly. I'll let you know how it goes. Guenter
[PATCH 2/2] mmc: sdhci-cadence: add Cadence SD4HC support
Add a driver for the Cadence SD4HC SD/SDIO/eMMC Controller.
For SD, it basically relies on the SDHCI standard code.
For eMMC, this driver provides some platform specific callbacks to
control the part of hardware that is specific to this IP design.
Signed-off-by: Masahiro Yamada
---
.../devicetree/bindings/mmc/sdhci-cadence.txt | 31 +++
drivers/mmc/host/Kconfig | 12 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-cadence.c | 279 +
4 files changed, 323 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
create mode 100644 drivers/mmc/host/sdhci-cadence.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
new file mode 100644
index 000..c18aaee
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
@@ -0,0 +1,31 @@
+* Cadence SD/SDIO/eMMC Host Controller
+
+Required properties:
+- compatible: should be "cdns,sd4hc".
+- reg: offset and length of the register set for the device. The region should
+ contain both Host Register Set (HRS) and Slot Register Set (SRS).
+- interrupts: a single interrupt specifier.
+- clocks: phandle to the input clock.
+
+Optional properties:
+For eMMC configuration, supported speed modes are not provided by the SDHCI
+Capabilities Register. Instead, the following properties should be specified
+if supported. See mmc.txt for details.
+- mmc-ddr-1_8v
+- mmc-ddr-1_2v
+- mmc-hs200-1_8v
+- mmc-hs200-1_2v
+- mmc-hs400-1_8v
+- mmc-hs400-1_2v
+
+Example:
+ emmc: sdhci@5a00 {
+ compatible = "cdns,sd4hc";
+ reg = <0x5a00 0x400>;
+ interrupts = <0 78 4>;
+ clocks = <&clk 4>;
+ bus-width = <8>;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ };
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 580b5a1..c1308ad 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -165,6 +165,18 @@ config MMC_SDHCI_OF_HLWD
If unsure, say N.
+config MMC_SDHCI_CADENCE
+ tristate "SDHCI support for the Cadence SD/SDIO/eMMC controller"
+ depends on MMC_SDHCI_PLTFM
+ depends on OF
+ select MMC_SDHCI_IO_ACCESSORS
+ help
+ This selects the Cadence SD/SDIO/eMMC driver.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
config MMC_SDHCI_CNS3XXX
tristate "SDHCI support on the Cavium Networks CNS3xxx SoC"
depends on ARCH_CNS3XXX
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index e49a82a..55f7193 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o
obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-pltfm.o
+obj-$(CONFIG_MMC_SDHCI_CADENCE)+= sdhci-cadence.o
obj-$(CONFIG_MMC_SDHCI_CNS3XXX)+= sdhci-cns3xxx.o
obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o
diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
new file mode 100644
index 000..ed49425
--- /dev/null
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ * Author: Masahiro Yamada
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "sdhci-pltfm.h"
+
+/* HRS - Host Register Set (specific to Cadence) */
+#define SDHCI_CDNS_HRS04 0x10/* PHY access port */
+#define SDHCI_CDNS_HRS04_ACK BIT(26)
+#define SDHCI_CDNS_HRS04_RD BIT(25)
+#define SDHCI_CDNS_HRS04_WR BIT(24)
+#define SDHCI_CDNS_HRS04_RDATA_SHIFT 12
+#define SDHCI_CDNS_HRS04_WDATA_SHIFT 8
+#define SDHCI_CDNS_HRS04_ADDR_SHIFT 0
+
+#define SDHCI_CDNS_HRS06 0x18/* eMMC control */
+#define SDHCI_CDNS_HRS06_TUNE_UP BIT(15)
+#define SDHCI_CDNS_HRS06_TUNE_SHIFT 8
+#define SDHCI_CDNS_HRS06_TUNE_MASK 0x3f
+#define SDHCI_CDNS_HRS06_MODE_MASK 0x7
+#define SDHCI_CDNS_HRS06_MODE_SD 0x0
+#define SDHCI_CDNS_HRS06_MODE_MMC_SDR
