Re: [BISECTED, REGRESSION] v4.7: Display lost on Kirkwood/OpenRD Client
Hi Aaro,
On mer., août 10 2016, Aaro Koskinen wrote:
> Hi,
>
> When upgrading from v4.6 --> v4.7, I lost the display/framebuffer on
> OpenRD-Client (the only pcie device on the board).
>
> Bisection points to:
>
> eb13cf8345e94a02e9872ca3e909596a5ddb5f90 is the first bad commit
> commit eb13cf8345e94a02e9872ca3e909596a5ddb5f90
> Author: Andrew Lunn
> Date: Sun Apr 3 04:03:47 2016 +0200
>
> ARM: dts: kirkwood: Fixup pcie DT warnings
>
> PCIe has a range property, so the unit name should contain an address.
> Make use of the label to enable individual PCIe busses. Also, fixup
> the synology dtsi file which added a label pcie2 rather than using the
> existing pcie1 label.
>
> Signed-off-by: Andrew Lunn
> Signed-off-by: Gregory CLEMENT
>
> Any ideas how to get display working again?
Thanks for this detailled report.
Could you try this patch:
diff --git a/arch/arm/boot/dts/kirkwood-openrd.dtsi
b/arch/arm/boot/dts/kirkwood-openrd.dtsi
index e4ecab112601..7175511a92da 100644
--- a/arch/arm/boot/dts/kirkwood-openrd.dtsi
+++ b/arch/arm/boot/dts/kirkwood-openrd.dtsi
@@ -116,6 +116,10 @@
};
};
+&pciec {
+ status = "okay";
+};
+
&pcie0 {
status = "okay";
};
Gregory
>
> Boot log with eb13cf8345e94a02e9872ca3e909596a5ddb5f90 (BAD):
>
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.6.0-rc1-mvebu-los_153e602-9-geb13cf8
> (aaro@amd-fx-6350) (gcc version 6.1.0 (GCC) ) #1 Thu Aug 11 00:42:14 EEST 2016
> [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE),
> cr=0005317f
> [0.00] CPU: VIVT data cache, VIVT instruction cache
> [0.00] Machine model: OpenRD Client
> [0.00] Memory policy: Data cache writeback
> [0.00] On node 0 totalpages: 131072
> [0.00] free_area_init_node: node 0, pgdat c05f7838, node_mem_map
> dfbfa000
> [0.00] Normal zone: 1024 pages used for memmap
> [0.00] Normal zone: 0 pages reserved
> [0.00] Normal zone: 131072 pages, LIFO batch:31
> [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [0.00] pcpu-alloc: [0] 0
> [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
> pages: 130048
> [ 0.00] Kernel command line: console=tty console=ttyS0,115200
> root=/dev/ram
> mtdparts=orion_nand:0x40@0x10(kernel),0x40@0x50(initramfs),0x1f70@0x90(scratch)
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> [0.00] Memory: 510160K/524288K available (4427K kernel code, 179K
> rwdata, 1304K rodata, 172K init, 599K bss, 14128K reserved, 0K cma-reserved)
> [0.00] Virtual kernel memory layout:
> [0.00] vector : 0x - 0x1000 ( 4 kB)
> [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
> [0.00] vmalloc : 0xe080 - 0xff80 ( 496 MB)
> [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB)
> [0.00] modules : 0xbf00 - 0xc000 ( 16 MB)
> [0.00] .text : 0xc0008000 - 0xc05a0ffc (5732 kB)
> [0.00] .init : 0xc05a1000 - 0xc05cc000 ( 172 kB)
> [0.00] .data : 0xc05cc000 - 0xc05f8c40 ( 180 kB)
> [0.00].bss : 0xc05f8c40 - 0xc068eb44 ( 600 kB)
> [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [0.00] NR_IRQS:16 nr_irqs:16 16
> [0.00] clocksource: orion_clocksource: mask: 0x max_cycles:
> 0x, max_idle_ns: 9556302233 ns
> [0.07] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every
> 10737418237ns
> [0.000195] Console: colour dummy device 80x30
> [0.000580] console [tty0] enabled
> [0.000617] Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
> [0.090098] pid_max: default: 32768 minimum: 301
> [0.090217] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [0.090258] Mountpoint-cache hash table entries: 1024 (order: 0, 4096
> bytes)
> [0.090807] CPU: Testing write buffer coherency: ok
> [0.091157] Setting up static identity map for 0x81e0 - 0x8238
> [0.091436] mvebu-soc-id: MVEBU SoC ID=0x6281, Rev=0x2
> [0.092639] devtmpfs: initialized
> [0.096287] clocksource: jiffies: mask: 0x max_cycles: 0x,
> max_idle_ns: 1911260446275 ns
> [0.096434] pinctrl core: initialized pinctrl subsystem
> [0.097010] NET: Registered protocol family 16
> [0.097460] DMA: preallocated 256 KiB pool for atomic coherent allocations
> [0.098480] cpuidle: using governor menu
> [0.098893] Feroceon L2: Enabling L2
> [0.098954] Feroceon L2: Cache support initialised.
> [0.099318] [Firmware Info]:
> /ocp@f100/ethernet-controller@72000/ethernet0-port@0: local-mac-address
Re: [PATCH] usb: core: Add runtime resume checking
On Thu, Aug 11, 2016 at 11:08:52AM +0800, Baolin Wang wrote: > Hi Alan, > > On 10 August 2016 at 22:25, Alan Stern wrote: > > On Wed, 10 Aug 2016, Baolin Wang wrote: > > > >> >> >> For example: No slave attached> usb interface runtime suspend > >> >> >> > usb device runtime suspend -> xhci suspend -> power off > >> >> >> usb controller. After that if the system wants to enter suspend > >> >> >> state, > >> >> >> then it also will issue usb_dev_suspend(), then the > >> >> >> pm_runtime_resume() function (issued in choose_wakeup() function) > >> >> >> will > >> >> >> return -ESHUTDOWN due to xhci has been suspend and hardware is not > >> >> >> accessible. > >> >> > > >> >> > Why the controller does not be resumed when the root hub has issued > >> >> > runtime resume? > >> >> > >> >> Because now there is no slave attached, we will not power on usb > >> >> controller and resume xhci. > >> >> > >> > > >> > I don't know why you set policy like this. Even the controller is > >> > resumed, it will still be suspended by system suspend. What's more, > >> > if you disallow it, how can you change your wakeup setting? > >> > Eg, at runtime suspend, we enable wakeup by default. But for system > >> > sleep, we disable wakeup by default. > >> > > >> > At runtime, if there is no device on the port, even we resumes the > >> > controller and roohub, it still will be suspended soon. > >> > >> For saving power, if there is no slave attached, why we need to power > >> on usb controller and resume xhci? Especially for mobile device. > > > > You need to power-on the USB controller in order to change the wakeup > > setting. > > pm_runtime_resume() function issued in choose_wakeup() can just resume > usb device, which can not power-on the USB controller and resume xHCI. > Cause the user won't know you need to power-on usb controller now, > then how to power-on the USB controller when changing wakeup setting? > > > > >> Moreover the usb device runtime suspend/resume is separate with xhci > >> suspend/resume, when xhci entered suspend state, only slave attaching > >> can resume xhci. > > > > That's right. Suppose the user wants the system to stay asleep when a > > slave attaches. But when you suspended the xHCI controller, it was set > > to wake up when a new slave attaches. So when a slave is attached, the > > controller will wake up the system. That's bad. > > > > If the wakeup setting needs to be changed when the system suspend > > begins, then you have to power-on the controller to make that change. > > > > Given a choice between using a little power or behaving incorrectly, > > you should choose to use the power. > > OK. But that is a real problem. It will pm_runtime_resume() falied > (issued in choose_wakeup()), cause usb controller has powered-off and > xHCI controller has suspended and we have no method to notify the user > to power-on USB controller. Any good suggestion to solve this, Alan > and Peter? Thanks. > Maybe you can show us the call stack why pm_runtime_resume has failed at your environment. -- Best Regards, Peter Chen
Re: [PATCH] relay: Use per CPU constructs for the relay channel buffer pointers
On Thu, Aug 11, 2016 at 12:35:40PM +0530, akash.g...@intel.com wrote: > From: Akash Goel > > relay essentially needs to maintain the per CPU array of channel buffer > pointers but it manually creates that array. > Instead its better to avail the per CPU constructs, provided by the > kernel, to allocate & access the array of pointer to channel buffers. > > Cc: Chris Wilson > Cc: Tvrtko Ursulin > Signed-off-by: Akash Goel This has the benefit of being a mechnical change and I could not think of a better way to express the per-cpu indirection. relay.h should probably include so that it pulls in the percpu api explicitly. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
Re: staging: ks7010: Replace three printk() calls by pr_err()
On Wed, Aug 10, 2016 at 09:41:37PM +0200, SF Markus Elfring wrote: > >> Please and and use pr_fmt > > > > Can't we use dev_* on the SDIO device? > > How should a connection be constructed from the data structure > "sdio_device_id" > to the corresponding device information for such an use case? What did you try so far? signature.asc Description: PGP signature
Re: patch mail rejected by vger.kernel.org
From: Eric Wong Date: Thu, 11 Aug 2016 06:59:04 + > Zhouyi Zhou wrote: >> Hi, >> Yesterday, I cced 5 patches to linux-kernel@vger.kernel.org using >> send-email, but all of them were >> rejected by mail server at vger.kernel.org as follows: >> "Dear yizhouz...@ict.ac.cn, Your message to linux-kernel@vger.kernel.org >> was rejected by the recipient domain. The error that the other server >> returned was: " SMTP error, RCPT TO: 451 4.7.1 Hello [159.226.251.20], for >> recipient address the policy analysis >> reported: zpostgrey: connect: Connection refused". Your original message is >> included as attachment." >> I have successfully posted to linux-kernel@vger.kernel.org previously. And >> maintainers have received my patch >> correctly yesterday. Do you know what is going on? > > +Cc: some folks who may actually know what's going on... > > It looks like the zpostgrey instance goes down and is not > restarting. I've noticed it on the git@vger list a few times > recently, too; but I'm not sure if any messages got rejected > for git@vger (we get a lot fewer messages than LKML). This happens from time to time, I fixed it this morning. When this happens just wait half a day and resend.
Re: [v2 PATCH] clk: rockchip: mark rk3399 hdcp_noc and vio_noc as critical
Am Mittwoch, 10. August 2016, 15:14:06 schrieb Guenter Roeck:
> On Tue, Aug 9, 2016 at 11:02 AM, Chris Zhong wrote:
> > Fix incorrect rk3399 aclk_vio gating bit, it should be 0, not 10. With
> > this modification, the aclk_vio_noc should be put into critical list,
> > since it is required by VOP.
> > And the Type-C DP need these clocks: aclk_hdcp_noc, hclk_hdcp_noc,
> > pclk_hdcp_noc. Mark them as critical to avoid someone close them.
> >
> > Signed-off-by: Chris Zhong
> > ---
> >
> > drivers/clk/rockchip/clk-rk3399.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/rockchip/clk-rk3399.c
> > b/drivers/clk/rockchip/clk-rk3399.c index b173711a..676b017 100644
> > --- a/drivers/clk/rockchip/clk-rk3399.c
> > +++ b/drivers/clk/rockchip/clk-rk3399.c
> > @@ -1073,7 +1073,7 @@ static struct rockchip_clk_branch
> > rk3399_clk_branches[] __initdata = {>
> > /* vio */
> > COMPOSITE(ACLK_VIO, "aclk_vio", mux_pll_src_cpll_gpll_ppll_p,
> > CLK_IGNORE_UNUSED,>
> > RK3399_CLKSEL_CON(42), 6, 2, MFLAGS, 0, 5, DFLAGS,
> >
> > - RK3399_CLKGATE_CON(11), 10, GFLAGS),
> > + RK3399_CLKGATE_CON(11), 0, GFLAGS),
> >
> > COMPOSITE_NOMUX(PCLK_VIO, "pclk_vio", "aclk_vio", 0,
> >
> > RK3399_CLKSEL_CON(43), 0, 5, DFLAGS,
> > RK3399_CLKGATE_CON(11), 1, GFLAGS),
> >
> > @@ -1470,6 +1470,9 @@ static const char *const
> > rk3399_cru_critical_clocks[] __initconst = {>
> > "aclk_cci_pre",
> > "aclk_gic",
> > "aclk_gic_noc",
> >
> > + "aclk_hdcp_noc",
> > + "hclk_hdcp_noc",
> > + "pclk_hdcp_noc",
> >
> > "pclk_perilp0",
> > "pclk_perilp0",
> > "hclk_perilp0",
> >
> > @@ -1489,6 +1492,7 @@ static const char *const
> > rk3399_cru_critical_clocks[] __initconst = {>
> > "gpll_hclk_perilp1_src",
> > "gpll_aclk_perilp0_src",
> > "gpll_aclk_perihp_src",
> >
> > + "aclk_vio_noc",
>
> I think there was a previous comment suggesting that this clock should
> be handled differently. Has this been resolved ?
The clock getting handled differently was pclk_grf_vio - aka the GRF part
needed. This one is the interconnect clock of the vio port (as far as I
understand that), which we currently don't model at all.
But if we did it would probably handled in some new part but not in the
graphics drivers.
So all looks well like it is here :-)
Heiko
Re: [PATCH 2/2] scripts/sortextable: set the variable mmap_failure
On Thu, Aug 11, 2016 at 09:52:55AM +0530, Maninder Singh wrote: > Currently mmap_failed variable is 1 for every case, so make it 0 > if mmap is success. > > Signed-off-by: Maninder Singh > Signed-off-by: Vaneet Narang See section 11) of Documentation/SubmittingPatches on how the sign-off chain should be done. It is not clear from your current submission what Vaneet's role is in the creation of this patch is. Ditto for your other patch. > --- > scripts/sortextable.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/scripts/sortextable.c b/scripts/sortextable.c > index 30b4e7c..0b6a31b 100644 > --- a/scripts/sortextable.c > +++ b/scripts/sortextable.c > @@ -106,6 +106,7 @@ static void *mmap_file(char const *fname) > } > addr = mmap(0, sb.st_size, PROT_READ|PROT_WRITE, MAP_SHARED, > fd_map, 0); > + mmap_failed = 0; This mmap_failed thing looks like a disaster. It is only needed so that we know to do munmap() but munmap() works even if the range is not mapped so you probably could go and remove that mmap_failed thing altogether. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
Re: [PATCH v6 07/10] drm/mediatek: add dsi transfer function
Hi, YT:
On Wed, 2016-08-10 at 15:24 +0800, YT Shen wrote:
> Hi CK,
>
> On Fri, 2016-08-05 at 18:08 +0800, CK Hu wrote:
> > Hi, YT:
> >
> > On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> > > From: shaoming chen
> > >
> > > add dsi read/write commands for transfer function
> > >
> > > Signed-off-by: shaoming chen
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_dsi.c | 261
> > >
> > > 1 file changed, 261 insertions(+)
> > >
[snip...]
> > > +
> > > +static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg
> > > *msg)
> > > +{
> > > + const char *tx_buf = msg->tx_buf;
> > > + u32 reg_val, i;
> > > + u16 wc16;
> > > + u8 config, data0, data1, type;
> > > +
> > > + if (MTK_DSI_HOST_IS_READ(type)) {
> >
> > 'type' is used before assigned.
> Will fix.
>
> >
> > > + config = 4;
> > > + data0 = tx_buf[0];
> > > +
> > > + if (msg->rx_len < 3)
> > > + type = MIPI_DSI_DCS_READ;
> > > + else
> > > + type = MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM;
> > > +
> > > + data1 = 0;
> > > + reg_val = (data1 << 24) | (data0 << 16) | (type << 8) | config;
> > > +
> > > + writel(reg_val, dsi->regs + DSI_CMDQ0);
> > > + mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE, 1);
> >
> > I think this part looks like 'else' part. The difference is type and
> > config. I think type should be msg->type and you can independently set
> > BIT(2) of config.
> msg->type only tells about read or write, for the details we need to
> check other parameters. This part is for read, the else part is for
> write short packet. Not only BIT(2) of config is different, but also
> type and data1 is changed. Such a change would lead to difficult to
> understand.
>
> >
> > > + } else if (msg->tx_len > 2) { /* send long packet */
> > > + config = 2;
> > > + type = msg->type;
> > > + wc16 = msg->tx_len;
> > > +
> > > + reg_val = (wc16 << 16) | (type << 8) | config;
> > > +
> > > + writel(reg_val, dsi->regs + DSI_CMDQ0);
> > > +
> > > + for (i = 0; i < msg->tx_len; i++)
> > > + writeb(tx_buf[i], dsi->regs + DSI_CMDQ0 + 4 + i);
> > > +
> > > + mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE,
> > > + 1 + (msg->tx_len + 3) / 4);
> > > + } else {/* send short packet */
> > > + config = 0;
> > > + data0 = tx_buf[0];
> > > +
> > > + if (msg->tx_len == 2) {
> > > + type = MIPI_DSI_DCS_SHORT_WRITE_PARAM;
> >
> > Why do you not set type as msg->type? This behavior looks like you
> > modify transfer type, but is this acceptable?
> msg->type only tells about read or write, for the details we need to
> check other parameters.
I think you could rewrite mtk_dsi_cmdq() as follow:
static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg
*msg)
{
u32 i;
u32 src_off = (msg->tx_len > 2) ? 4 : 2;
u32 cmdq_size = (msg->tx_len > 2) ? 1 + (msg->tx_len + 3) / 4 : 1;
u32 config = (msg->tx_len > 2) ? BIT(1) : 0;
u32 type = msg->type;
if (MTK_DSI_HOST_IS_READ(type))
config |= BIT(2);
writel((type << 8) || config, dsi->regs + DSI_CMDQ0);
for (i = 0; i < msg->tx_len; i++)
writeb(msg->tx_buf[i], dsi->regs + DSI_CMDQ0 + src_off + i);
mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE, cmdq_size);
}
If DSI HW does not support some type and it can be transferred to other
type, you could add a transfer function like this
static u8 mtk_dsi_map_to_supported_type(u8 type)
{
switch(type) {
case MIPI_DSI_DCS_SHORT_WRITE:
return MIPI_DSI_DCS_SHORT_WRITE_PARAM;
}
return type;
}
and then
u32 type = mtk_dsi_map_to_supported_type(msg->type);
>
> >
> > > + data1 = tx_buf[1];
> > > + } else {
> > > + type = MIPI_DSI_DCS_SHORT_WRITE;
> > > + data1 = 0;
> > > + }
> > > +
> > > + reg_val = (data1 << 24) | (data0 << 16) | (type << 8) | config;
> > > +
> > > + writel(reg_val, dsi->regs + DSI_CMDQ0);
> > > + mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE, 1);
> > > + }
> > > +}
> > > +
[snip...]
> >
> > Regards,
> > CK
> >
>
>
Regards,
CK
[RFC PATCH] proc_sysctl: free invalidate proc_sys_dentry
From: Fengtiantian I find a issue in dentry cache used by sysctl proc. If register sysctl proc file ,access the file and then unregister this file, dentry in cache will keep increasing, and cause CPU softlockup。 I test in the kernel 3.10.0-327. My testcase is : #/bin/sh while : do brctl addbr abc cat /proc/sys/net/ipv6/conf/abc/autoconf brctl delbr abc done run this script , see the dentry in slabinfo keep increasing: cat /proc/slabinfo | grep den dentry106624 187026192 422 : tunables000 : slabdata 4453 4453 0 And because the dentry path is same, their dentry name hash is same, so all dentry will link in one hash list. The function __d_lookup time cost will increase too. In the situation, if run anther script: #/bin/sh touch testfile1 while : do mv testfile1 testfile2 mv testfile2 testfile1 done The CPU softlocup happen: [45029.115429] BUG: soft lockup - CPU#10 stuck for 22s! [cat:18953] [45029.121607] Modules linked in: bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter openvswitch(OE) nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack gre libcrc32c kboxdriver(O) kbox(O) ipmi_devintf ipmi_si ipmi_msghandler intel_powerclamp coretemp intel_rapl crc32_pclmul ghash_clmulni_intel aesni_intel sr_mod cdrom iTCO_wdt iTCO_vendor_support lrw gf128mul mei_me glue_helper sb_edac ablk_helper cryptd mei sg ioatdma edac_core shpchp i2c_i801 pcspkr lpc_ich mfd_core vhost_net tun vhost macvtap macvlan vfio_pci ip_tables ext3 mbcache jbd usb_storage sd_mod crc_t10dif crct10dif_generic kvm_intel(O) kvm(O) irqbypass crct10dif_pclmul crct10dif_common crc32c_intel serio_raw igb ahci libahci i2c_algo_bit libata i2c_core dca megaraid_sas ptp pps_core dm_mod vfio_iommu_type1 vfio [last unloaded: signo_catch] [45029.121649] CPU: 10 PID: 18953 Comm: cat Tainted: G OEL --- 3.10.0-327.22.2.23.next.x86_64 #1 [45029.121650] Hardware name: HUAWEI TECHNOLOGIES CO.,LTD. Tecal BH622 V2/BC01SRSA0, BIOS RMISV019 05/10/2012 [45029.121652] task: 880486c1e780 ti: 8804c5698000 task.ti: 8804c5698000 [45029.121653] RIP: 0010:[] [] proc_sys_compare+0x49/0xd0 [45029.121658] RSP: 0018:8804c569bbb0 EFLAGS: 0246 [45029.121659] RAX: RBX: 1308 RCX: 0002 [45029.121660] RDX: 0002 RSI: 8804921173b8 RDI: 8804a239f038 [45029.121661] RBP: 8804c569bbc8 R08: 0063 R09: [45029.121662] R10: 1308 R11: 880492117380 R12: 880a182c3b00 [45029.121663] R13: 8804c569bbc8 R14: 88067ffdb008 R15: 8116db65 [45029.121664] FS: 7fae0d59f740() GS:8806676c() knlGS: [45029.121665] CS: 0010 DS: ES: CR0: 80050033 [45029.121666] CR2: 7fae0d0a3540 CR3: 0004a014d000 CR4: 000407e0 [45029.121667] DR0: DR1: DR2: [45029.121668] DR3: DR6: 0ff0 DR7: 0400 [45029.121669] Stack: [45029.121670] 880492117388 88065ba2ccc0 8804c569be60 8804c569bc18 [45029.121672] 811fa47c 880492117380 8804a239f038 88040003 [45029.121674] 05d9368a 8804c569be60 88065ba2ccc0 8804c569bc97 [45029.121676] Call Trace: [45029.121680] [] __d_lookup+0x14c/0x160 [45029.121681] [] d_lookup+0x2a/0x50 [45029.121684] [] lookup_dcache+0x30/0xb0 [45029.121685] [] __lookup_hash+0x2d/0x60 [45029.121689] [] lookup_slow+0x42/0xa7 [45029.121691] [] link_path_walk+0x83f/0x8e0 [45029.121695] [] ? radix_tree_lookup_slot+0x22/0x50 [45029.121697] [] path_openat+0xa3/0x4c0 [45029.121700] [] ? __do_fault+0x401/0x510 [45029.121702] [] do_filp_open+0x4b/0xb0 [45029.121705] [] ? __alloc_fd+0xa7/0x130 [45029.121707] [] do_sys_open+0xf3/0x1f0 [45029.121709] [] SyS_open+0x1e/0x20 Signed-off-by: Fengtiantian --- fs/proc/proc_sysctl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c index 5e57c3e..4ee1093 100644 --- a/fs/proc/proc_sysctl.c +++ b/fs/proc/proc_sysctl.c @@ -850,6 +850,8 @@ static int proc_sys_compare(const struct dentry *parent, const struct dentry *de return 1; if (memcmp(name->name, str, len)) return 1; + if (!PROC_I(dentry->d_inode)->sysctl->unregistering == 0) + return 0; head = rcu_dereference(PROC_I(inode)->sysctl); return !head || !sysctl_is_seen(head); } -- 1.8.3.1
Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver
On Wed, Aug 10, 2016 at 10:28:45PM +0200, Oliver Hartkopp wrote: > Hi Andreas, > > On 08/09/2016 08:10 AM, Andreas Werner wrote: > >On Mon, Aug 08, 2016 at 04:35:34PM +0200, Wolfgang Grandegger wrote: > > >>You specify here one echo_skb but it's not used anywhere. Local loopback > >>seems not to be implemented. > >> > > > >Agree with you, will set it to "0". > > No, the local loopback is mandetory! > > >>> > >>>Hm ok, but if i check alloc_candev() in drivers/net/can/dev.c > >>>it is not mandatory. > > It is. > > Even those drivers that show up to use zero echo skbs in alloc_candev() > implement the echo functionality correct. > > Just check 'git grep IFF_ECHO'. Even grcan.c and janz-ican3.c have IFF_ECHO > set - but implement it in a different way without using the provided > machanism from dev.c . > Ok I am with you. > >>>In the Documentation/networking/can.txt > >>>there is also a "should" and a fallback mechnism if the driver > >>>does not support the local loopback. > > But this fallback mechanism is bad - really bad! > > E.g. the slcan.c driver sends a stream of CAN frames without knowing whether > the frames ever hit the wire. The slcan driver is more less for hobby users. > The CAN frame echo with IFF_ECHO gives a correct representation of the > traffic on the wire - including the correct timestamps. > > You really want to know whether a CAN frame was sent correctly on the bus > instead of getting some shortcut info from inside the network layer. > . Thanks for the explanation. I make it more clear why its mandatory. > >> > >>Well, s/driver/hardware/ ! Local loopback is the preferred mechanism. > >> > > > >Sure... > > > >>>I'm currently ok with this fallback mechanism. > > /me not. > > >>>Anyway I am not sure that the driver can handle the echo skb correctly. > >>>If i understand it correctly, the can_get_echo_skb() is normally called > >>>on a "TX done IRQ" to get the skb and loop it back. > > ack. > > >>>I do not have such a "TX done IRQ" and have not implemented implemented > >>>and added the local looback. > > I'm not really sure how grcan.c and janz-ican3.c implemented the echo > functionality but they must have faced a similar situation. > I will check those driver to get more information about the implementation. > A local loopback inside the CAN controller which is generated after > successful transmit is an excellent implementation with excellent > timestamps. The only problem for you is to detect the looped CAN frames and > match them to the skb pointer of the outgoing frame to 'receive' the correct > echo skb. > At the moment, i think there is no way to detect those looped frames. I will talk to our IC designer and discuss this issue with him. Maybe we have the possibility to get a local loopback inside the CAN controller. This seems to be the best way to do it. > When you send CAN frames to an unconnected CAN bus it can't be sent out due > to the missing acknowledge from other nodes. So when you send frames and you > get echo frames due to the fallback mode your cool CAN controller degrades > to slcan level. > I agree with you. This is what we do not want to have. > Regards, > Oliver > > ps. Do you have any URL where one can get the MEN 16Z192 spec? No sorry, its not available. Regards Andy
Re: [PATCH v3 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K
Am Donnerstag, den 04.08.2016, 10:38 +0800 schrieb Bibby Hsieh: > From: Junzhi Zhao > > Pixel clock should be 297MHz when resolution is 4K. > > Signed-off-by: Junzhi Zhao > Signed-off-by: Bibby Hsieh > --- > drivers/gpu/drm/mediatek/mtk_dpi.c |8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c > b/drivers/gpu/drm/mediatek/mtk_dpi.c > index d05ca79..a90af59 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c > @@ -438,10 +438,14 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi, > } > > pix_rate = 1000UL * mode->clock; > - if (mode->clock <= 74000) > + if (mode->clock <= 27000) > + factor = 16 * 3; > + else if (mode->clock <= 74250) > factor = 8 * 3; > - else > + else if (mode->clock <= 167000) > factor = 4 * 3; > + else > + factor = 2 * 3; > pll_rate = pix_rate * factor; > > dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n", Could you add a comment why this also changes the 74 MHz limit to 74.25 MHz and that adds a factor 16*3 for clocks <= 27 MHz ? regards Philipp
Re: [PATCH v2] usb: core: Add runtime resume checking in choose_wakeup()
On Thu, Aug 11, 2016 at 11:11:08AM +0800, Baolin Wang wrote: > On 10 August 2016 at 22:31, Alan Stern wrote: > > On Wed, 10 Aug 2016, Baolin Wang wrote: > > > >> Considering strict power management for mobile device, we should also power > >> off the usb controller if there are no slaves attached even though it is > >> usb > >> host function, but it will meet usb device resume failure in below > >> situation. > >> > >> Suppose that no slave attached > usb interface runtime suspend > > >> usb device runtime suspend -> xhci suspend -> power off usb > >> controller. > >> After that if the system wants to enter suspend state, then it also will > >> issue > >> usb_dev_suspend(), then the pm_runtime_resume() issued in choose_wakeup() > >> function will return '-ESHUTDOWN' due to xhci has been suspend and > >> hardware is > >> not accessible. > > > > No, this is wrong. The pm_runtime_resume in choose_wakeup() should > > cause the xHCI controller to resume also. > > But now it won't, it just resume usb device not xHCI controller. I > suppose mainline kernel does not sopport this now. > Why? It works ok at my environment. The controller is the ancestor of the USB device, if the USB device would like to be woken up, the controller will be woken up first. -- Best Regards, Peter Chen
[PATCH v9 0/2] [media] atmel-isc: add driver for Atmel ISC
The Image Sensor Controller driver includes two parts. 1) Driver code to implement the ISC function. 2) Device tree binding documentation, it describes how to add the ISC in device tree. Test result with v4l-utils. # v4l2-compliance -f v4l2-compliance SHA : not available Driver Info: Driver name : atmel_isc Card type : Atmel Image Sensor Controller Bus info : platform:atmel_isc f0008000.isc Driver version: 4.7.0 Capabilities : 0x8421 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x0421 Video Capture Streaming Extended Pix Format Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK test for unlimited opens: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Test input 0: Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK (Not Supported) test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 0: Stream using all formats: test MMAP for Format BA81, Frame Size 640x480@60.00 Hz: Stride 640, Field None: OK test MMAP for Format YUYV, Frame Size 640x480@60.00 Hz: Stride 1280, Field None: OK Total: 45, Succeeded: 45, Failed: 0, Warnings: 0 Changes in v9: - Set the default format in fuction 'isc_async_complete'. - Register the video device after everything is configured. Changes in v8: - Power on the sensor on the first open in function 'isc_open'. - Power off the sensor on the last release in function 'isc_release'. - Remove the switch of the pipeline. Changes in v7: - Add enum_framesizes and enum_frameintervals. - Call s_stream(0) when stream start fail. - Fill the device_caps field of struct video_device with V4L2_CAP_STREAMING and V4L2_CAP_VIDEO_CAPTURE. - Initialize the dev of struct vb2_queue. - Set field to FIELD_NONE if the pix field is not supported. - Return the result directly when call g/s_parm of subdev. Changes in v6: - Add "iscck" and "gck" to clock-names. Changes in v5: - Modify the macro definition and the related code. - Add clock-output-names. Changes in v4: - Modify the isc clock code since the dt is changed. - Remove the isc clock nodes. Changes in v3: - Add pm runtime feature. - Modify the isc clock code since the dt is changed. - Remove the 'atmel,sensor-preferred'. - Modify the isc clock node according to the Rob's remarks. Changes in v2: - Add "depends on COMMON_CLK" and "VIDEO_V4L2_SUBDEV_API" i
[PATCH v9 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver
DT binding documentation for ISC driver.
Acked-by: Rob Herring
Signed-off-by: Songjun Wu
---
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Add "iscck" and "gck" to clock-names.
Changes in v5:
- Add clock-output-names.
Changes in v4:
- Remove the isc clock nodes.
Changes in v3:
- Remove the 'atmel,sensor-preferred'.
- Modify the isc clock node according to the Rob's remarks.
Changes in v2:
- Remove the unit address of the endpoint.
- Add the unit address to the clock node.
- Avoid using underscores in node names.
- Drop the "0x" in the unit address of the i2c node.
- Modify the description of 'atmel,sensor-preferred'.
- Add the description for the ISC internal clock.
.../devicetree/bindings/media/atmel-isc.txt| 65 ++
1 file changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt
diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt
b/Documentation/devicetree/bindings/media/atmel-isc.txt
new file mode 100644
index 000..bbe0e87c
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isc.txt
@@ -0,0 +1,65 @@
+Atmel Image Sensor Controller (ISC)
+--
+
+Required properties for ISC:
+- compatible
+ Must be "atmel,sama5d2-isc".
+- reg
+ Physical base address and length of the registers set for the device.
+- interrupts
+ Should contain IRQ line for the ISC.
+- clocks
+ List of clock specifiers, corresponding to entries in
+ the clock-names property;
+ Please refer to clock-bindings.txt.
+- clock-names
+ Required elements: "hclock", "iscck", "gck".
+- #clock-cells
+ Should be 0.
+- clock-output-names
+ Should be "isc-mck".
+- pinctrl-names, pinctrl-0
+ Please refer to pinctrl-bindings.txt.
+
+ISC supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+isc: isc@f0008000 {
+ compatible = "atmel,sama5d2-isc";
+ reg = <0xf0008000 0x4000>;
+ interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
+ clocks = <&isc_clk>, <&iscck>, <&isc_gclk>;
+ clock-names = "hclock", "iscck", "gck";
+ #clock-cells = <0>;
+ clock-output-names = "isc-mck";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_isc_base &pinctrl_isc_data_8bit
&pinctrl_isc_data_9_10 &pinctrl_isc_data_11_12>;
+
+ port {
+ isc_0: endpoint {
+ remote-endpoint = <&ov7740_0>;
+ hsync-active = <1>;
+ vsync-active = <0>;
+ pclk-sample = <1>;
+ };
+ };
+};
+
+i2c1: i2c@fc028000 {
+ ov7740: camera@21 {
+ compatible = "ovti,ov7740";
+ reg = <0x21>;
+ clocks = <&isc>;
+ clock-names = "xvclk";
+ assigned-clocks = <&isc>;
+ assigned-clock-rates = <2400>;
+
+ port {
+ ov7740_0: endpoint {
+ remote-endpoint = <&isc_0>;
+ };
+ };
+ };
+};
--
2.7.4
Re: [PATCH v2 30/44] x86/unwind: add new unwind interface and implementations
On Aug 10, 2016 5:16 PM, "Josh Poimboeuf" wrote:
>
> On Wed, Aug 10, 2016 at 12:25:11AM -0700, Andy Lutomirski wrote:
> > On Aug 10, 2016 2:27 AM, "Josh Poimboeuf" wrote:
> > >
> > > On Tue, Aug 09, 2016 at 06:17:41PM -0500, Nilay Vaish wrote:
> > > > On 4 August 2016 at 17:22, Josh Poimboeuf wrote:
> > > > > diff --git a/arch/x86/kernel/unwind_frame.c
> > > > > b/arch/x86/kernel/unwind_frame.c
> > > > > new file mode 100644
> > > > > index 000..f28f1b5
> > > > > --- /dev/null
> > > > > +++ b/arch/x86/kernel/unwind_frame.c
> > > > > @@ -0,0 +1,84 @@
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +#define FRAME_HEADER_SIZE (sizeof(long) * 2)
> > > > > +
> > > > > +unsigned long unwind_get_return_address(struct unwind_state *state)
> > > > > +{
> > > > > + unsigned long *addr_p = unwind_get_return_address_ptr(state);
> > > > > + unsigned long addr;
> > > > > +
> > > > > + if (state->stack_info.type == STACK_TYPE_UNKNOWN)
> > > > > + return 0;
> > > > > +
> > > > > + addr = ftrace_graph_ret_addr(state->task, &state->graph_idx,
> > > > > *addr_p,
> > > > > +addr_p);
> > > > > +
> > > > > + return __kernel_text_address(addr) ? addr : 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(unwind_get_return_address);
> > > > > +
> > > > > +static bool update_stack_state(struct unwind_state *state, void
> > > > > *addr,
> > > > > + size_t len)
> > > > > +{
> > > > > + struct stack_info *info = &state->stack_info;
> > > > > +
> > > > > + if (on_stack(info, addr, len))
> > > > > + return true;
> > > > > +
> > > > > + if (get_stack_info(info->next_sp, state->task, info,
> > > > > + &state->stack_mask))
> > > > > + goto unknown;
> > > > > +
> > > > > + if (!on_stack(info, addr, len))
> > > > > + goto unknown;
> > > > > +
> > > > > + return true;
> > > > > +
> > > > > +unknown:
> > > > > + info->type = STACK_TYPE_UNKNOWN;
> > > > > + return false;
> > > > > +}
> > > > > +
> > > > > +bool unwind_next_frame(struct unwind_state *state)
> > > > > +{
> > > > > + unsigned long *next_bp;
> > > > > +
> > > > > + if (unwind_done(state))
> > > > > + return false;
> > > > > +
> > > > > + next_bp = (unsigned long *)*state->bp;
> > > > > +
> > > > > + /*
> > > > > +* Make sure the next frame is on a valid stack and can be
> > > > > accessed
> > > > > +* safely.
> > > > > +*/
> > > > > + if (!update_stack_state(state, next_bp, FRAME_HEADER_SIZE))
> > > > > + return false;
> > > > > +
> > > > > + /* move to the next frame */
> > > > > + state->bp = next_bp;
> > > > > + return true;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(unwind_next_frame);
> > > > > +
> > > > > +void __unwind_start(struct unwind_state *state, struct task_struct
> > > > > *task,
> > > > > + struct pt_regs *regs, unsigned long *sp)
> > > > > +{
> > > > > + memset(state, 0, sizeof(*state));
> > > > > +
> > > > > + state->task = task;
> > > > > + state->bp = get_frame_pointer(task, regs);
> > > > > +
> > > > > + get_stack_info(state->bp, state->task, &state->stack_info,
> > > > > + &state->stack_mask);
> > > > > + update_stack_state(state, state->bp, FRAME_HEADER_SIZE);
> > > > > +
> > > > > + /* unwind to the first frame after the specified stack
> > > > > pointer */
> > > > > + while (state->bp < sp && !unwind_done(state))
> > > > > + unwind_next_frame(state);
> > > >
> > > > Do we unwind all the frames here? It seems strange to me that in a
> > > > function named __unwind_start(), we unwind all the frames.
> > >
> > > It just skips any stack frames before the specified "sp" pointer.
> > > Several callers use this, for example, to start at regs->sp instead of
> > > the current stack frame. I'll try to make the comment clearer.
> > >
> >
> > Are you checking the right condition? Shouldn't this check that sp is
> > in bounds for the current stack if a stack switch happened?
>
> You're right.
>
> > I admit I don't fully understand the use case. If someone wants to
> > start a trace in the middle, shouldn't they just pass regs in?
>
> The regs aren't always available. Some callers just want to skip the
> first few frames so the stack dump code itself isn't traced.
I suspect that all users are okay with your algorithm simply because
they don't switch stacks. Maybe the thing to do is to stop advancing
when sp is passed or if the stack switches at all.
Could you point me at a user that passes anything other than regs->sp
here? On brief inspection, I haven't found any at all.
--Andy
[PATCH v9 1/2] [media] atmel-isc: add the Image Sensor Controller code
Add driver for the Image Sensor Controller. It manages incoming data from a parallel based CMOS/CCD sensor. It has an internal image processor, also integrates a triple channel direct memory access controller master interface. Signed-off-by: Songjun Wu --- Changes in v9: - Set the default format in fuction 'isc_async_complete'. - Register the video device after everything is configured. Changes in v8: - Power on the sensor on the first open in function 'isc_open'. - Power off the sensor on the last release in function 'isc_release'. - Remove the switch of the pipeline. Changes in v7: - Add enum_framesizes and enum_frameintervals. - Call s_stream(0) when stream start fail. - Fill the device_caps field of struct video_device with V4L2_CAP_STREAMING and V4L2_CAP_VIDEO_CAPTURE. - Initialize the dev of struct vb2_queue. - Set field to FIELD_NONE if the pix field is not supported. - Return the result directly when call g/s_parm of subdev. Changes in v6: None Changes in v5: - Modify the macro definition and the related code. Changes in v4: - Modify the isc clock code since the dt is changed. Changes in v3: - Add pm runtime feature. - Modify the isc clock code since the dt is changed. Changes in v2: - Add "depends on COMMON_CLK" and "VIDEO_V4L2_SUBDEV_API" in Kconfig file. - Correct typos and coding style according to Laurent's remarks - Delete the loop while in 'isc_clk_enable' function. - Replace 'hsync_active', 'vsync_active' and 'pclk_sample' with 'pfe_cfg0' in struct isc_subdev_entity. - Add the code to support VIDIOC_CREATE_BUFS in 'isc_queue_setup' function. - Invoke isc_config to configure register in 'isc_start_streaming' function. - Add the struct completion 'comp' to synchronize with the frame end interrupt in 'isc_stop_streaming' function. - Check the return value of the clk_prepare_enable in 'isc_open' function. - Set the default format in 'isc_open' function. - Add an exit condition in the loop while in 'isc_config'. - Delete the hardware setup operation in 'isc_set_format'. - Refuse format modification during streaming in 'isc_s_fmt_vid_cap' function. - Invoke v4l2_subdev_alloc_pad_config to allocate and initialize the pad config in 'isc_async_complete' function. - Remove the '.owner = THIS_MODULE,' in atmel_isc_driver. - Replace the module_platform_driver_probe() with module_platform_driver(). drivers/media/platform/Kconfig|1 + drivers/media/platform/Makefile |2 + drivers/media/platform/atmel/Kconfig |9 + drivers/media/platform/atmel/Makefile |1 + drivers/media/platform/atmel/atmel-isc-regs.h | 165 +++ drivers/media/platform/atmel/atmel-isc.c | 1512 + 6 files changed, 1690 insertions(+) create mode 100644 drivers/media/platform/atmel/Kconfig create mode 100644 drivers/media/platform/atmel/Makefile create mode 100644 drivers/media/platform/atmel/atmel-isc-regs.h create mode 100644 drivers/media/platform/atmel/atmel-isc.c diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index f25344b..b23db17 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -111,6 +111,7 @@ source "drivers/media/platform/s5p-tv/Kconfig" source "drivers/media/platform/am437x/Kconfig" source "drivers/media/platform/xilinx/Kconfig" source "drivers/media/platform/rcar-vin/Kconfig" +source "drivers/media/platform/atmel/Kconfig" config VIDEO_TI_CAL tristate "TI CAL (Camera Adaptation Layer) driver" diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 21771c1..37b6c75 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -58,6 +58,8 @@ obj-$(CONFIG_VIDEO_XILINX)+= xilinx/ obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin/ +obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel/ + ccflags-y += -I$(srctree)/drivers/media/i2c obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/ diff --git a/drivers/media/platform/atmel/Kconfig b/drivers/media/platform/atmel/Kconfig new file mode 100644 index 000..867dca2 --- /dev/null +++ b/drivers/media/platform/atmel/Kconfig @@ -0,0 +1,9 @@ +config VIDEO_ATMEL_ISC + tristate "ATMEL Image Sensor Controller (ISC) support" + depends on VIDEO_V4L2 && COMMON_CLK && VIDEO_V4L2_SUBDEV_API && HAS_DMA + depends on ARCH_AT91 || COMPILE_TEST + select VIDEOBUF2_DMA_CONTIG + select REGMAP_MMIO + help + This module makes the ATMEL Image Sensor Controller available + as a v4l2 device. \ No newline at end of file diff --git a/drivers/media/platform/atmel/Makefile b/drivers/media/platform/atmel/Makefile new file mode 100644 index 000..9d7c999 --- /dev/null +++ b/drivers/media/platform/atmel/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_ATMEL_ISC) += atmel-isc.o diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h new file
Re: [RFC PATCH v7 1/7] Restartable sequences system call
On Aug 11, 2016 12:01 AM, "Mathieu Desnoyers"
wrote:
>
> - On Aug 10, 2016, at 4:09 PM, Andy Lutomirski l...@amacapital.net wrote:
>
> > On Wed, Aug 10, 2016 at 1:06 PM, Mathieu Desnoyers
> > wrote:
>
>
>
> >>> u64 is a perfectly valid, if odd, userspace pointer on all
> >>> architecures that I know of, and it's certainly a valid userspace
> >>> pointer on x86 32-bit userspace (the high bits will just all be zero).
> >>> Can you just use u64?
> >>
> >> My concern is about a 32-bit user-space putting garbage rather than zeroes
> >> (on purpose) to fool the kernel on those upper 32 bits. Doing
> >>
> >> compat_ptr((compat_uptr_t)rseq_cs.start_ip)
> >>
> >> effectively ends up clearing the upper 32 bits.
> >>
> >> But since we only use those pointer values for comparisons, perhaps we
> >> just don't care if a 32-bit userspace app try to shoot itself in
> >> the foot by passing garbage upper 32 bits ?
> >>
> >
> > How is garbage in the high bits any different than garbage in any
> > other bits in there?
>
> It's not :)
>
> >
> >>
> >>> If this would be a performance problem on ARM, then maybe that's a
> >>> reason to use compat helpers.
> >>
> >> We already use 64-bit values for the pointers, even on 32-bit. Normally
> >> userspace just puts zeroes in the top bits. It's mostly a question of
> >> clearing the top 32 bits or not when loading them in the kernel. If we
> >> don't need to, then I can remove the compat code entirely, and we don't
> >> care about user_64bit_mode() anymore, as you initially recommended.
> >> Does it make sense ?
> >
> > Yes, I think so. I'd suggest just honoring all the bits.
>
> OK, will do !
>
> >
> >>
> >>>
>
> >
> >
> +SYSCALL_DEFINE2(rseq, struct rseq __user *, rseq, int, flags)
> +{
> +if (unlikely(flags))
> +return -EINVAL;
> >>>
> >>> (add whitespace)
> >>
> >> fixed.
> >>
> >>>
> +if (!rseq) {
> +if (!current->rseq)
> +return -ENOENT;
> +return 0;
> +}
> >
> > This looks entirely wrong. Setting rseq to NULL fails if it's already
> > NULL but silently does nothing if rseq is already set? Surely it
> > should always succeed and it should actually do something if rseq is
> > set.
>
> From the proposed rseq(2) manpage:
>
> "A NULL rseq value can be used to check whether rseq is registered
> for the current thread."
>
> The implementation does just that: it returns -1, errno=ENOENT if no
> rseq is currently registered, or 0 if rseq is currently registered.
> >>>
> >>> I think that's problematic. Why can't you unregister an existing
> >>> rseq? If you can't, how is a thread supposed to clean up after
> >>> itself?
> >>>
> >>
> >> Unregistering an existing thread rseq would require that we keep reference
> >> counting, in case multiple libs and/or the app are using rseq. I am
> >> trying to keep things as simple as needed.
> >>
> >> If I understand your concern, the problematic scenario would be at
> >> thread exit (this is my current approximate understanding of glibc
> >> handling of library TLS variable reclaim at thread exit):
> >>
> >> thread exits in userspace:
> >> - glibc frees its rseq TLS memory area (in case the TLS is in a library),
> >> - thread preempted before really exiting,
> >> - kernel reads/writes to freed TLS memory.
> >> - corruption may occur (e.g. memory re-allocated by another thread
> >> already)
> >>
> >> Am I getting it right ?
> >
> > Yes.
>
> Hrm, then we should:
>
> - add a rseq_refcount field to the task struct,
> - increment this refcount whenever rseq receives a registration, after
> ensuring that we are registering the same address as was previously
> requested by preceding registrations for the thread (except if the
> refcount was 0),
> - When rseq receives a NULL address, decrement refcount. Set address to
> NULL when it reaches 0.
>
> Doing the refcounting in kernel-space rather than user-space allows us to
> keep both registration/unregistration and refcount atomic, which simplify
> things if we plan to use rseq from signal handlers.
>
> With current glibc, a library that would lazily register and use rseq
> without knowledge of the application would then have to use
> pthread_key_create()
> to set a destr_function to run at thread exit, which would take care of
> unregistration.
That sounds reasonable at first glance.
>
> We could add a RSEQ_FORCE_UNREGISTER flag to rseq flags to allow future
> glibc versions to force unregistering rseq before freeing its TLS memory,
> just in case a userspace library omits to unregister itself.
Sounds good too.
Re: [PATCH] fs/char_dev: fix cdev_put() vs f_op->release() use-after-free
On Wed, Aug 10, 2016 at 10:16 PM, Al Viro wrote: > On Wed, Aug 10, 2016 at 09:49:22PM -0700, Dan Williams wrote: > >> Where dax_dev_release() is the f_op->release() method, and is >> implemented to simply drop the final references on our driver objects: >> >> struct dax_dev *dax_dev = filp->private_data; >> struct device *dev = dax_dev->dev; >> >> dev_dbg(dax_dev->dev, "%s\n", __func__); >> put_device(dev); >> dax_dev_put(dax_dev); >> >> The dax_dev object embeds a 'struct cdev' which means f_op->release() >> may free cdev, so __fput() needs to drop the cdev reference before >> calling f_op->release(). > > NAK. You *can't* free a structure that contains kobj with currently > positive refcount. Ever. If you embed a struct kobj into something, > you must use the refcount of that kobj (or one of its ancestors) to > control the lifetime of containing object. If your dax_dev_put() can > trigger freeing of dax_dev despite the still-positive refcount of > embedded cdev.kobj, it is fundamentally broken. Ah, ok. I missed that cdev_put() drops a parent kobj ref, NULL in my case. So that "put_device(dev)" above can just be delegated to cdev_put() and I can remove the kref behind dax_dev_put(). Thank you for straightening me out!
Re: [PATCH] seccomp: Fix tracer exit notifications during fatal signals
On Wed, Aug 10, 2016 at 4:37 PM, Kees Cook wrote:
> This fixes a ptrace vs fatal pending signals bug as manifested in seccomp
> now that ptrace was reordered to happen after ptrace. The short version is
> that seccomp should not attempt to call do_exit() while fatal signals are
> pending under a tracer. This was needlessly paranoid. Instead, the syscall
> can just be skipped and normal signal handling, tracer notification, and
> process death can happen.
>
> Slightly edited original bug report:
>
> If a tracee task is in a PTRACE_EVENT_SECCOMP trap, or has been resumed
> after such a trap but not yet been scheduled, and another task in the
> thread-group calls exit_group(), then the tracee task exits without the
> ptracer receiving a PTRACE_EVENT_EXIT notification. Test case here:
> https://gist.github.com/khuey/3c43ac247c72cef8c956ca73281c9be7
>
> The bug happens because when __seccomp_filter() detects
> fatal_signal_pending(), it calls do_exit() without dequeuing the fatal
> signal. When do_exit() sends the PTRACE_EVENT_EXIT notification and
> that task is descheduled, __schedule() notices that there is a fatal
> signal pending and changes its state from TASK_TRACED to TASK_RUNNING.
> That prevents the ptracer's waitpid() from returning the ptrace event.
> A more detailed analysis is here:
> https://github.com/mozilla/rr/issues/1762#issuecomment-237396255.
>
> Reported-by: Robert O'Callahan
> Reported-by: Kyle Huey
> Fixes: 93e35efb8de4 ("x86/ptrace: run seccomp after ptrace")
> Signed-off-by: Kees Cook
> ---
> kernel/seccomp.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index ef6c6c3f9d8a..0db7c8a2afe2 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -605,12 +605,16 @@ static int __seccomp_filter(int this_syscall, const
> struct seccomp_data *sd,
> ptrace_event(PTRACE_EVENT_SECCOMP, data);
> /*
> * The delivery of a fatal signal during event
> -* notification may silently skip tracer notification.
> -* Terminating the task now avoids executing a system
> -* call that may not be intended.
> +* notification may silently skip tracer notification,
> +* which could leave us with a potentially unmodified
> +* syscall that the tracer would have liked to have
> +* changed. Since the process is about to die, we just
> +* force the syscall to be skipped and let the signal
> +* kill the process and correctly handle any tracer exit
> +* notifications.
> */
What does "The delivery of a fatal signal during event notification
may silently skip tracer notification" mean? Is that describing
exactly the issue you're fixing? If so, maybe that sentence should be
deleted.
Otherwise looks good to me.
--Andy
Re: [PATCH 1/1] arm64: Remove stack duplicating code from jprobes
On 10/08/16 21:44, David Long wrote: > From: "David A. Long" > > Because the arm64 calling standard allows stacked function arguments to be > anywhere in the stack frame, do not attempt to duplicate the stack frame for > jprobes handler functions. > > Documenation changes to describe this issue have been broken out into a nit: "Documentation" > separate patch in order to simultaneously address them in other > architecture(s). > > Signed-off-by: David A. Long > Acked-by: Masami Hiramatsu Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny...
Re: [PATCH 1/2] remoteproc: core: Add rproc OF look-up functions
On Wed, 10 Aug 2016, Suman Anna wrote: > On 08/10/2016 04:19 PM, Bjorn Andersson wrote: > > On Wed 10 Aug 14:04 PDT 2016, Suman Anna wrote: > > > >> On 08/10/2016 03:40 PM, Bjorn Andersson wrote: > >>> On Wed 10 Aug 12:37 PDT 2016, Suman Anna wrote: > >>> > Hi Lee, Bjorn, > > On 08/10/2016 12:40 PM, Bjorn Andersson wrote: > > On Tue 19 Jul 08:49 PDT 2016, Lee Jones wrote: > > > >> - of_rproc_by_index(): look-up and obtain a reference to a rproc > >>using the DT phandle "rprocs" and a index. > >> > >> - of_rproc_by_name(): lookup and obtain a reference to a rproc > >>using the DT phandle "rprocs" and "rproc-names". > >> > >> Signed-off-by: Ludovic Barre > >> Signed-off-by: Lee Jones > >> --- > > > > I'm happy with this, so I whipped up a binding document describing our > > two new properties. Waiting for an opinion on that before I merge this. > > Yeah, I like the two new API too, I have just about run into the need > for the same on my product trees. We can probably make it less > complicated than what the current series is. The wkup_m3_ipc usage was > before there was any standardization on the property names, so we went > with a ti, prefixed property specific to the wkup_m3_ipc node and a > general API that is agnostic of property name. We don't have all the > pieces for PM on AM335x/AM437x SoCs on upstream kernel yet, so we should > be able to switch over to using the new property as we cannot achieve > the desired functionality even though we can boot the wkup_m3. > > >>> > >>> Glad to hear you're onboard with dropping the old property name, even if > >>> it's later. > >>> > Here's what I propose: > 1. Let's not burden the new of_get_rproc_by_index() API with having to > fall-back and look for ti,rprocs. The rproc_get_by_phandle() core logic > of looking up against the rproc list is self-contained, and the API > usage is limited to just the wkup_m3_ipc driver at the moment. > 2. Keep the rproc_get_by_phandle API as is but mark it as deprecated. > IMHO, the rename of this API to of_get_rproc_by_phandle() in Patch 2 but > using a device node pointer as input argument doesn't add any value. > 3. Provide a fallback in wkup_m3_ipc driver to look for both rprocs and > ti,rproc property, while switching over the node to use rprocs property. > 4. We can get rid of the rproc_get_by_phandle() API after the > wkup_m3_ipc transition is done to use of_get_rproc_by_index() API. > > >>> > >>> I don't fancy the idea of leaving the kernel builds with a deprecation > >>> warning for some time and I don't feel the cost of carrying those 2 > >>> extra statements is a bigger issue than keeping a deprecated API around. > >>> And it will be less than the dance we have to do in wkup_m3_ipc. > >>> > >>> So I think that we should merge these patches and if it can be concluded > >>> that we don't need backwards compatibility with the old DT property we > >>> can drop the inner conditional in the API. > >> > >> Yeah, I am fine with dropping the inner ti,rproc processing in the new > >> of_rproc_get_by_index() API and keeping it clean. What's not clear to me > >> is why we would still need a get_by_phandle API alongside the two new > >> API once the wkup_m3_ipc is converted to the new API? Or is it just to > >> clean up the consumer interface? If latter, I will fixup the wkup_m3_ipc > >> driver without the need for remoteproc core changes, and switch over to > >> the new API. > >> > > > > of_get_rproc_by_phandle() is just a convenience for not having to get by > > index 0, as most drivers is only having one rproc. > > OK, then better to name this as simply of_rproc_get(), the _by_phandle() > does not match up with the other two of_get_rproc_xxx API. I'm not opposed to changing the call to of_rproc_get(). However, I'm not sure what you mean about it not matching the other OF functions. The nomenclature should be the same of_get_rproc_*(), no? > Suggest also a rename from of_get_rproc_xxx to of_rproc_get_xxx like in > other subsystems. This suggestion does the opposite and does not fit in with the majority of the of_* calls scattered around in other subsystems: of_get_drm of_get_coresight of_get_fb of_get_i2c of_get_regulator of_get_gpio of_get_mac of_get_display of_get_videomode Vs of_irq_get of_reset_get of_graph_get of_msi_get of_usb_get of_genpd_get These guys have both oddly. of_get_dma, of_dma_get of_get_pci, of_pci_get of_get_phy, of_phy_get -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 1/3] net: stmmac: dwmac-rk: add rk3366 & rk3399 specific data
Add constants and callback functions for the dwmac on rk3228/rk3229 socs.
As can be seen, the base structure is the same, only registers and the
bits in them moved slightly.
Signed-off-by: Roger Chen
---
.../devicetree/bindings/net/rockchip-dwmac.txt | 4 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 226 +
2 files changed, 228 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
index cccd945..8c066e6 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
@@ -3,8 +3,8 @@ Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC)
The device node has following properties.
Required properties:
- - compatible: Can be one of "rockchip,rk3228-gmac", "rockchip,rk3288-gmac",
- "rockchip,rk3368-gmac"
+ - compatible: Can be one of "rockchip,rk3288-gmac", "rockchip,rk3366-gmac",
+ "rockchip,rk3368-gmac", "rockchip,rk3399-gmac"
- reg: addresses and length of the register sets for the device.
- interrupts: Should contain the GMAC interrupts.
- interrupt-names: Should contain the interrupt names "macirq".
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 9210591..4e6a270 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -301,6 +301,118 @@ static const struct rk_gmac_ops rk3288_ops = {
.set_rmii_speed = rk3288_set_rmii_speed,
};
+#define RK3366_GRF_SOC_CON60x0418
+#define RK3366_GRF_SOC_CON70x041c
+
+/* RK3366_GRF_SOC_CON6 */
+#define RK3366_GMAC_PHY_INTF_SEL_RGMII (GRF_BIT(9) | GRF_CLR_BIT(10) | \
+GRF_CLR_BIT(11))
+#define RK3366_GMAC_PHY_INTF_SEL_RMII (GRF_CLR_BIT(9) | GRF_CLR_BIT(10) | \
+GRF_BIT(11))
+#define RK3366_GMAC_FLOW_CTRL GRF_BIT(8)
+#define RK3366_GMAC_FLOW_CTRL_CLR GRF_CLR_BIT(8)
+#define RK3366_GMAC_SPEED_10M GRF_CLR_BIT(7)
+#define RK3366_GMAC_SPEED_100M GRF_BIT(7)
+#define RK3366_GMAC_RMII_CLK_25M GRF_BIT(3)
+#define RK3366_GMAC_RMII_CLK_2_5M GRF_CLR_BIT(3)
+#define RK3366_GMAC_CLK_125M (GRF_CLR_BIT(4) | GRF_CLR_BIT(5))
+#define RK3366_GMAC_CLK_25M(GRF_BIT(4) | GRF_BIT(5))
+#define RK3366_GMAC_CLK_2_5M (GRF_CLR_BIT(4) | GRF_BIT(5))
+#define RK3366_GMAC_RMII_MODE GRF_BIT(6)
+#define RK3366_GMAC_RMII_MODE_CLR GRF_CLR_BIT(6)
+
+/* RK3366_GRF_SOC_CON7 */
+#define RK3366_GMAC_TXCLK_DLY_ENABLE GRF_BIT(7)
+#define RK3366_GMAC_TXCLK_DLY_DISABLE GRF_CLR_BIT(7)
+#define RK3366_GMAC_RXCLK_DLY_ENABLE GRF_BIT(15)
+#define RK3366_GMAC_RXCLK_DLY_DISABLE GRF_CLR_BIT(15)
+#define RK3366_GMAC_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 8)
+#define RK3366_GMAC_CLK_TX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 0)
+
+static void rk3366_set_to_rgmii(struct rk_priv_data *bsp_priv,
+ int tx_delay, int rx_delay)
+{
+ struct device *dev = &bsp_priv->pdev->dev;
+
+ if (IS_ERR(bsp_priv->grf)) {
+ dev_err(dev, "%s: Missing rockchip,grf property\n", __func__);
+ return;
+ }
+
+ regmap_write(bsp_priv->grf, RK3366_GRF_SOC_CON6,
+RK3366_GMAC_PHY_INTF_SEL_RGMII |
+RK3366_GMAC_RMII_MODE_CLR);
+ regmap_write(bsp_priv->grf, RK3366_GRF_SOC_CON7,
+RK3366_GMAC_RXCLK_DLY_ENABLE |
+RK3366_GMAC_TXCLK_DLY_ENABLE |
+RK3366_GMAC_CLK_RX_DL_CFG(rx_delay) |
+RK3366_GMAC_CLK_TX_DL_CFG(tx_delay));
+}
+
+static void rk3366_set_to_rmii(struct rk_priv_data *bsp_priv)
+{
+ struct device *dev = &bsp_priv->pdev->dev;
+
+ if (IS_ERR(bsp_priv->grf)) {
+ dev_err(dev, "%s: Missing rockchip,grf property\n", __func__);
+ return;
+ }
+
+ regmap_write(bsp_priv->grf, RK3366_GRF_SOC_CON6,
+RK3366_GMAC_PHY_INTF_SEL_RMII | RK3366_GMAC_RMII_MODE);
+}
+
+static void rk3366_set_rgmii_speed(struct rk_priv_data *bsp_priv, int speed)
+{
+ struct device *dev = &bsp_priv->pdev->dev;
+
+ if (IS_ERR(bsp_priv->grf)) {
+ dev_err(dev, "%s: Missing rockchip,grf property\n", __func__);
+ return;
+ }
+
+ if (speed == 10)
+ regmap_write(bsp_priv->grf, RK3366_GRF_SOC_CON6,
+RK3366_GMAC_CLK_2_5M);
+ else if (speed == 100)
+ regmap_write(bsp_priv->grf, RK3366_GRF_SOC_CON6,
+RK3366_GMAC_CLK_25M);
+ else if (speed == 1000)
+ regmap_write(bsp_priv->grf, RK3366_GRF_SOC_CON6,
+RK3366_GMAC_CLK_125M);
+ else
+ dev_err(de
[PATCH 3/3] arm64: dts: rockchip: add GMAC dt nodes for RK3399 evb
This patch add ethernet GMAC dt nodes for RK3399 evaluation board.
Signed-off-by: Roger Chen
---
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
index d33aa06..5a076e0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -69,6 +69,13 @@
regulator-max-microvolt = <330>;
};
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_phy";
@@ -134,3 +141,19 @@
};
};
};
+
+&gmac {
+ phy-supply = <&vcc_phy>;
+ phy-mode = "rgmii";
+ clock_in_out = "input";
+ snps,reset-gpio = <&gpio3 15 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 1 5>;
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
--
1.9.1
[PATCH 2/3] arm64: dts: rockchip: add GMAC dt nodes for rk3399 SoC
This patch adds ethernet GMAC dt notes for Rockchip RK3399 SoC.
Signed-off-by: Roger Chen
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 79
1 file changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index a6dd623..76f3e44 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -199,6 +199,25 @@
};
};
+ gmac: ethernet@fe30 {
+ compatible = "rockchip,rk3399-gmac";
+ reg = <0x0 0xfe30 0x0 0x1>;
+ rockchip,grf = <&grf>;
+ interrupts = ;
+ interrupt-names = "macirq";
+ clocks = <&cru SCLK_MAC>, <&cru SCLK_MAC_RX>,
+ <&cru SCLK_MAC_TX>, <&cru SCLK_MACREF>,
+ <&cru SCLK_MACREF_OUT>, <&cru ACLK_GMAC>,
+ <&cru PCLK_GMAC>;
+ clock-names = "stmmaceth", "mac_clk_rx",
+ "mac_clk_tx", "clk_mac_ref",
+ "clk_mac_refout", "aclk_mac",
+ "pclk_mac";
+ resets = <&cru SRST_A_GMAC>;
+ reset-names = "stmmaceth";
+ status = "disabled";
+ };
+
sdio0: dwmmc@fe31 {
compatible = "rockchip,rk3399-dw-mshc",
"rockchip,rk3288-dw-mshc";
@@ -955,6 +974,66 @@
drive-strength = <13>;
};
+ gmac {
+ rgmii_pins: rgmii-pins {
+ rockchip,pins =
+ /* mac_txclk */
+ <3 17 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_rxclk */
+ <3 14 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_mdio */
+ <3 13 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_txen */
+ <3 12 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_clk */
+ <3 11 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxdv */
+ <3 9 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_mdc */
+ <3 8 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxd1 */
+ <3 7 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxd0 */
+ <3 6 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_txd1 */
+ <3 5 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_txd0 */
+ <3 4 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_rxd3 */
+ <3 3 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxd2 */
+ <3 2 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_txd3 */
+ <3 1 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_txd2 */
+ <3 0 RK_FUNC_1 &pcfg_pull_none_13ma>;
+ };
+
+ rmii_pins: rmii-pins {
+ rockchip,pins =
+ /* mac_mdio */
+ <3 13 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_txen */
+ <3 12 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_clk */
+ <3 11 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxer */
+ <3 10 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxdv */
+ <3 9 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_mdc */
+ <3 8 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxd1 */
+ <3 7 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_rxd0 */
+ <3 6 RK_FUNC_1 &pcfg_pull_none>,
+ /* mac_txd1 */
+ <3 5 RK_FUNC_1 &pcfg_pull_none_13ma>,
+ /* mac_txd0 */
+ <3 4 RK_FUNC_1 &pcfg_pull_none_13ma>;
+ };
+ };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins =
--
1.9.1
RE: [PATCH] KVM: x86: Expose more Intel AVX512 feature to guest
> Expose AVX512DQ, AVX512BW, AVX512VL feature to guest. > Its spec can be found at: > https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf > > Signed-off-by: Luwei Kang > --- > arch/x86/kvm/cpuid.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index > 7597b42..a2d007c 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -366,7 +366,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 > *entry, u32 function, > F(FSGSBASE) | F(BMI1) | F(HLE) | F(AVX2) | F(SMEP) | > F(BMI2) | F(ERMS) | f_invpcid | F(RTM) | f_mpx | F(RDSEED) | > F(ADX) | F(SMAP) | F(AVX512F) | F(AVX512PF) | F(AVX512ER) | > - F(AVX512CD) | F(CLFLUSHOPT) | F(CLWB) | F(PCOMMIT); > + F(AVX512CD) | F(CLFLUSHOPT) | F(CLWB) | F(PCOMMIT) | > + F(AVX512DQ) | F(AVX512BW) | F(AVX512VL); > Hi Paolo, What is your opinion? > /* cpuid 0xD.1.eax */ > const u32 kvm_cpuid_D_1_eax_x86_features = > -- > 2.7.4
Re: [PATCH 1/9] remoteproc: core: Ensure error message is clear
On Wed, 10 Aug 2016, Suman Anna wrote:
> On 08/09/2016 01:12 PM, Lee Jones wrote:
> > On Tue, 09 Aug 2016, Bjorn Andersson wrote:
> >
> >> On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote:
> >>
> >>> Before this patch, the dma_alloc_coherent() failure path printed out:
> >>>
> >>> "dma_alloc_coherent err: 16760832"
> >>>
> >>> ... alluding to the Linux error code being 16760832, but seeing as
> >>> Linux error codes are all negative, this looks like a signed/unsigned
> >>> issue. In fact, the message is trying to print the length of the
> >>> requested memory region. Let's clear that up.
> >>>
> >>> While we're at it, let's standardise the way 'len' is printed. In
> >>> all other locations 'len' is in hex prefixed by a '0x' for clarity.
> >>>
> >>> Signed-off-by: Lee Jones
> >>
> >> Acked-by: Bjorn Andersson
> >
> > Again, this can just be applied.
> >
> >>> ---
> >>> drivers/remoteproc/remoteproc_core.c | 5 +++--
> >>> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/remoteproc/remoteproc_core.c
> >>> b/drivers/remoteproc/remoteproc_core.c
> >>> index aea29a75c..3566dc9 100644
> >>> --- a/drivers/remoteproc/remoteproc_core.c
> >>> +++ b/drivers/remoteproc/remoteproc_core.c
> >>> @@ -581,7 +581,7 @@ static int rproc_handle_carveout(struct rproc *rproc,
> >>> return -EINVAL;
> >>> }
> >>>
> >>> - dev_dbg(dev, "carveout rsc: da %x, pa %x, len %x, flags %x\n",
> >>> + dev_dbg(dev, "carveout rsc: da %x, pa %x, len 0x%x, flags %x\n",
> >>> rsc->da, rsc->pa, rsc->len, rsc->flags);
>
> If you are modifying this trace, it's better to following the leading 0x
> convention on all arguments rather than just the length.
I'd be concerned if anyone thought it a good idea to print out memory
addresses !0x. The length is the only parameter there which could
(and has) cause confusion.
However, the fix-up is trivial, so I'm happy to oblige. I'll leave
the final decision to Bjorn and fix-up if he sees it necessary.
> >>> carveout = kzalloc(sizeof(*carveout), GFP_KERNEL);
> >>> @@ -590,7 +590,8 @@ static int rproc_handle_carveout(struct rproc *rproc,
> >>>
> >>> va = dma_alloc_coherent(dev->parent, rsc->len, &dma, GFP_KERNEL);
> >>> if (!va) {
> >>> - dev_err(dev->parent, "dma_alloc_coherent err: %d\n", rsc->len);
> >>> + dev_err(dev->parent,
> >>> + "failed to allocate dma memory: len 0x%x\n", rsc->len);
> >>> ret = -ENOMEM;
> >>> goto free_carv;
> >>> }
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 05/19] arm64: rename COMPAT to AARCH32_EL0 in Kconfig
Hi, Yury
On 2016/6/18 7:54, Yury Norov wrote:
From: Andrew Pinski
In this patchset ILP32 ABI support is added. Additionally to AARCH32,
which is binary-compatible with ARM, ILP32 is (mostly) ABI-compatible.
From now, AARCH32_EL0 (former COMPAT) config option means the support of
AARCH32 userspace, ARM64_ILP32 - support of ILP32 ABI (see next patches),
and COMPAT indicates that one of them, or both, is enabled.
Where needed, CONFIG_COMPAT is changed over to use CONFIG_AARCH32_EL0 instead
Reviewed-by: David Daney
Signed-off-by: Andrew Pinski
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
Signed-off-by: Bamvor Jian Zhang
Signed-off-by: Yury Norov
...
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index c173d32..af200a8 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -134,15 +134,17 @@ static int c_show(struct seq_file *m, void *v)
*/
seq_puts(m, "Features\t:");
if (compat) {
-#ifdef CONFIG_COMPAT
- for (j = 0; compat_hwcap_str[j]; j++)
- if (compat_elf_hwcap & (1 << j))
- seq_printf(m, " %s",
compat_hwcap_str[j]);
-
- for (j = 0; compat_hwcap2_str[j]; j++)
- if (compat_elf_hwcap2 & (1 << j))
- seq_printf(m, " %s",
compat_hwcap2_str[j]);
-#endif /* CONFIG_COMPAT */
+#ifdef CONFIG_AARCH32_EL0
I saw that compat_hwcap_str and compat_hwcap2_str is defined when
"CONFIG_COMPAT" is true. Why we only change it to CONFIG_AARCH32_EL0
in c show()?
+ if (personality(current->personality) == PER_LINUX32) {
And "compat" is "personality(current->personality) == PER_LINUX32;",
it seems that there is no need to add this twice.
Regards
Bamvor
+ for (j = 0; compat_hwcap_str[j]; j++)
+ if (compat_elf_hwcap & (1 << j))
+ seq_printf(m, " %s",
compat_hwcap_str[j]);
+
+ for (j = 0; compat_hwcap2_str[j]; j++)
+ if (compat_elf_hwcap2 & (1 << j))
+ seq_printf(m, " %s",
compat_hwcap2_str[j]);
+ }
+#endif /* CONFIG_AARCH32_EL0 */
} else {
for (j = 0; hwcap_str[j]; j++)
if (elf_hwcap & (1 << j))
[PATCH 0/3] support GMAC for RK3399 & RK3366
This series adds registers description for RK3366 & RK3399 GMAC. And also DT nodes for RK3399 SoC and EVB. Roger Chen (3): net: stmmac: dwmac-rk: add rk3366 & rk3399 specific data arm64: dts: rockchip: add GMAC dt nodes for rk3399 SoC arm64: dts: rockchip: add GMAC dt nodes for RK3399 evb .../devicetree/bindings/net/rockchip-dwmac.txt | 4 +- arch/arm64/boot/dts/rockchip/rk3399-evb.dts| 23 +++ arch/arm64/boot/dts/rockchip/rk3399.dtsi | 79 +++ drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 226 + 4 files changed, 330 insertions(+), 2 deletions(-) -- 1.9.1
Re: [PATCH v2] usb: core: Add runtime resume checking in choose_wakeup()
Hi Peter, On 11 August 2016 at 14:52, Peter Chen wrote: > On Thu, Aug 11, 2016 at 11:11:08AM +0800, Baolin Wang wrote: >> On 10 August 2016 at 22:31, Alan Stern wrote: >> > On Wed, 10 Aug 2016, Baolin Wang wrote: >> > >> >> Considering strict power management for mobile device, we should also >> >> power >> >> off the usb controller if there are no slaves attached even though it is >> >> usb >> >> host function, but it will meet usb device resume failure in below >> >> situation. >> >> >> >> Suppose that no slave attached > usb interface runtime suspend > >> >> usb device runtime suspend -> xhci suspend -> power off usb >> >> controller. >> >> After that if the system wants to enter suspend state, then it also will >> >> issue >> >> usb_dev_suspend(), then the pm_runtime_resume() issued in choose_wakeup() >> >> function will return '-ESHUTDOWN' due to xhci has been suspend and >> >> hardware is >> >> not accessible. >> > >> > No, this is wrong. The pm_runtime_resume in choose_wakeup() should >> > cause the xHCI controller to resume also. >> >> But now it won't, it just resume usb device not xHCI controller. I >> suppose mainline kernel does not sopport this now. >> > > Why? It works ok at my environment. The controller is the ancestor of > the USB device, if the USB device would like to be woken up, the Yes, the controller is the ancestor of the USB device. The routine will be like below if we resume USB device: usb_resume_device() > generic_resume() > hcd_bus_resume() ---> xhci_bus_resume(), but now xHCI is not accessible due to xhci_suspend() is issued and USB controller is power off when no slave attached. If we want to resume USB device sucessfully, we must power-on USB controller and resume xhci by issuing xhci_resume(), but now how to trigger the USB controller action and resume xHCI just from pm_runtime_resume() function? > controller will be woken up first. I suppose your xHCI controller will not be suspended and your USB controller will not be power-off when no slave attached (but now system is not in suspend state), right? -- Baolin.wang Best Regards
Re: [PATCH 0/7] ima: carry the measurement list across kexec
On 09/08/16 22:36, Mimi Zohar wrote: > On Tue, 2016-08-09 at 15:19 +1000, Balbir Singh wrote: >> >> On 04/08/16 22:24, Mimi Zohar wrote: >>> The TPM PCRs are only reset on a hard reboot. In order to validate a >>> TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list >>> of the running kernel must be saved and then restored on the subsequent >>> boot. >>> >>> The existing securityfs binary_runtime_measurements file conveniently >>> provides a serialized format of the IMA measurement list. This patch >>> set serializes the measurement list in this format and restores it. >>> >>> This patch set pre-req's Thiago Bauermann's "kexec_file: Add buffer >>> hand-over for the next kernel" patch set* for actually carrying the >>> serialized measurement list across the kexec. >>> >>> Mimi >>> >> >> Hi, Mimi >> >> I am trying to convince myself of the security of the solution. I asked >> Thiago as well, but may be I am be lagging behind in understanding. >> >> We trust the kernel to hand over PCR values of the old kernel (which >> cannot be validated) to the IMA subsystem in the new kernel for storage. >> I guess the idea is for ima_add_boot_aggregate to do the right thing? >> How do we validate what the old kernel is giving us? Why do we care for >> the old measurement list? Is it still of significance in the new kernel? >> > > Hi Balbir, > > To validate the hardware TPM PCR values requires walking the measurement > list simulating the TPM extend operation. The resulting values should > match the hardware TPM PCRs. > > In the case of a soft reboot, the TPM PCRs are not reset to 0, so all > the measurements of the running system, including those from previous > soft reboots, need to be included in the measurement list. Without > these measurements, the simulated PCR values will not match the hardware > TPM PCR values. Thus the need for this patch set. > > Measurements can not be added/removed/changed in the measurement list > without it being detectable. > Thanks Mimi I think that makes sense So effectively we do first kernel boot -> second kernel boot -> and so on Balbir Singh
[PATCH] x86/irq: do not substract irq_tlb_count from irq_call_count
Since commit 52aec3308db8 ("x86/tlb: replace INVALIDATE_TLB_VECTOR by
CALL_FUNCTION_VECTOR"), the tlb remote shootdown is done through call
function vector. That commit didn't take care of irq_tlb_count so later
commit fd0f5869724f ("x86: Distinguish TLB shootdown interrupts from
other functions call interrupts") tried to fix it.
The fix assumes every increase of irq_tlb_count has a corresponding
increase of irq_call_count. So the irq_call_count is always bigger than
irq_tlb_count and we could substract irq_tlb_count from irq_call_count.
Unfortunately this is not true for the smp_call_function_single case.
The IPI is only sent if the target CPU's call_single_queue is empty when
adding a csd into it in generic_exec_single. That means if two threads
are both adding flush tlb csds to the same CPU's call_single_queue, only
one IPI is sent. In other words, the irq_call_count is incremented by 1
but irq_tlb_count is incremented by 2. Over time, irq_tlb_count will be
bigger than irq_call_count and the substract will produce a very large
irq_call_count value due to overflow.
Considering that:
1 it's not worth to send more IPIs for the sake of accurate counting of
irq_call_count in generic_exec_single;
2 it's not easy to tell if the call function interrupt is for TLB
shootdown in __smp_call_function_single_interrupt.
Not to exclude TLB shootdown from call function count seems to be the
simplest fix and this patch just did that.
This is found by LKP's cyclic performance regression tracking recently
with the vm-scalability test suite. I have bisected to commit
0a7ce4b5a632 ("mm/rmap: share the i_mmap_rwsem"). This commit didn't do
anything wrong but revealed the irq_call_count problem. IIUC, the commit
makes rwc->remap_one in rmap_walk_file concurrent with multiple threads.
When remap_one is try_to_unmap_one, then multiple threads could queue
flush tlb to the same CPU but only one IPI will be sent.
Since the commit enter Linux v3.19, the counting problem only shows up
from v3.19. Considering this is a behaviour change, I'm not sure if I
should add the stable tag here.
Signed-off-by: Aaron Lu
---
arch/x86/include/asm/hardirq.h | 4
arch/x86/kernel/irq.c | 3 +--
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
index 7178043b0e1d..59405a248fc2 100644
--- a/arch/x86/include/asm/hardirq.h
+++ b/arch/x86/include/asm/hardirq.h
@@ -22,10 +22,6 @@ typedef struct {
#ifdef CONFIG_SMP
unsigned int irq_resched_count;
unsigned int irq_call_count;
- /*
-* irq_tlb_count is double-counted in irq_call_count, so it must be
-* subtracted from irq_call_count when displaying irq_call_count
-*/
unsigned int irq_tlb_count;
#endif
#ifdef CONFIG_X86_THERMAL_VECTOR
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 61521dc19c10..9f669fdd2010 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -102,8 +102,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
seq_puts(p, " Rescheduling interrupts\n");
seq_printf(p, "%*s: ", prec, "CAL");
for_each_online_cpu(j)
- seq_printf(p, "%10u ", irq_stats(j)->irq_call_count -
- irq_stats(j)->irq_tlb_count);
+ seq_printf(p, "%10u ", irq_stats(j)->irq_call_count);
seq_puts(p, " Function call interrupts\n");
seq_printf(p, "%*s: ", prec, "TLB");
for_each_online_cpu(j)
--
2.5.5
Re: [PATCH v4 3/4] drm/mediatek: Add gamma correction.
On Thu, Aug 11, 2016 at 09:32:59AM +0200, Philipp Zabel wrote:
> Am Donnerstag, den 28.07.2016, 10:22 +0800 schrieb Bibby Hsieh:
> > Add gamma set function to correct brightness values.
> > It applies arbitrary mapping curve to compensate the
> > incorrect transfer function of the panel.
> >
> > Signed-off-by: Bibby Hsieh
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 31
> > +++
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 10 +
> > 4 files changed, 49 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 24aa3ba..cbb460a5 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
> > *crtc,
> > }
> > if (pending_planes)
> > mtk_crtc->pending_planes = true;
> > + if (crtc->state->color_mgmt_changed)
> > + for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > + mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> > }
> >
> > static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > @@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > .reset = mtk_drm_crtc_reset,
> > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > .atomic_destroy_state = mtk_drm_crtc_destroy_state,
> > + .gamma_set = drm_atomic_helper_legacy_gamma_set,
> > };
> >
> > static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > @@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > &mtk_crtc->planes[1].base, pipe);
> > if (ret < 0)
> > goto unprepare;
> > -
> > + drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
> > + drm_helper_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
> > + MTK_LUT_SIZE);
>
> I have applied all four patches and rebased onto v4.8-rc1, replacing
> drm_helper_crtc_enable_color_mgmt with:
>
> drm_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
> true, MTK_LUT_SIZE);
BTW that looks wrong (already in the original). AFAICS the patch just
handled the gamma_lut, not the degamma_lut, so telling you have both
is not right.
>
> (See https://patchwork.kernel.org/patch/9160987/)
>
> regards
> Philipp
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
Re: [REGRESSION] 362899b ("macvtap: switch to use skb array") causes oops during teardown
On 2016年08月11日 00:40, Cornelia Huck wrote:
I'm hitting the following oops during shutdown (halt command in guest)
of a libvirt-managed qemu guest 100% of the time:
[ 108.920486] Unable to handle kernel pointer dereference in virtual kernel
address space
[ 108.920492] Failing address: 6b6b6b6b6b6b6000 TEID: 6b6b6b6b6b6b6803
[ 108.920495] Fault in home space mode while using kernel ASCE.
[ 108.920504] AS:00e20007 R3:0024
[ 108.920588] Oops: 0038 ilc:2 [#1] PREEMPT SMP
[ 108.920592] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack
nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp iptable_filter ip_tables
x_tables bridge stp llc ghash_s390 prng ecb aes_s390 des_s390 des_generic
sha512_s390 sha256_s390 sha1_s390 sha_common lockd grace vhost_net tun vhost
macvtap macvlan kvm sunrpc dm_multipath dm_mod autofs4
[ 108.920628] CPU: 8 PID: 2648 Comm: qemu-system-s39 Not tainted
4.8.0-rc1-00031-gd3d312e #25
[ 108.920630] Hardware name: IBM 2964 NC9 704
(LPAR)
[ 108.920634] Krnl PSW : 0704e0018000 0064a3e8
(kfree_skb+0x38/0x288)
[ 108.920640]R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0
RI:0 EA:3
Krnl GPRS: 9fb04a5f 0007a7a37d48 6b6b6b6b6b6b6b6b 03ff80721af0
[ 108.920645]0078d626 0007a7a34000
0008
[ 108.920647]0007b0f04210 0007bde65718 03ff80721afa
6b6b6b6b6b6b6b6b
[ 108.920648]0007bde65698 00807180 03ff80721afa
0007a7a37d08
[ 108.920656] Krnl Code: 0064a3da: b90400aelgr
%r10,%r14
0064a3de: b90400b2 lgr %r11,%r2
#0064a3e2: ec280121007c cgij%r2,0,8,64a624
>0064a3e8: 581020e4 l %r1,228(%r2)
0064a3ec: ec160005017e cij %r1,1,6,64a3f6
0064a3f2: a7f4000b brc 15,64a408
0064a3f6: a718 lhi %r1,-1
0064a3fa: eb1120e400f8 laa %r1,%r1,228(%r2)
[ 108.920673] Call Trace:
[ 108.920675] ([<0007a7a37d28>] 0x7a7a37d28)
[ 108.920679] ([<03ff80721afa>] macvtap_sock_destruct+0x92/0xa8 [macvtap])
[ 108.920681] ([<00647026>] __sk_destruct+0x3e/0x1f0)
[ 108.920684] ([<03ff80723ed8>] macvtap_release+0x150/0x1b0 [macvtap])
[ 108.920688] ([<0031bd72>] __fput+0x132/0x230)
[ 108.920691] ([<0015f7aa>] task_work_run+0xb2/0xe8)
[ 108.920695] ([<0078e494>] system_call+0xdc/0x270)
[ 108.920697] INFO: lockdep is turned off.
[ 108.920698] Last Breaking-Event-Address:
[ 108.920700] [<03ff80721100>] 0x3ff80721100
[ 108.920703] Kernel panic - not syncing: Fatal exception: panic_on_oops
s390 host with a qeth device as the sole networking interface, one
network interface in the guest, using vhost (I can try to figure out
what libvirt is doing, if needed).
If I revert 362899b ("macvtap: switch to use skb array") and its
companion patch 0d7eacb ("macvtap: correctly free skb during socket
destruction"), starting a guest via libvirt and halting it again from
the guest works 100% of the time again.
I'm willing to collect debug info if you tell me what you need.
Thanks for the reporting.
This looks like a use-after-free. Could you pls try the following patch
to see it if fixes your issue?
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index a38c0da..070e329 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -275,7 +275,6 @@ static void macvtap_put_queue(struct macvtap_queue *q)
rtnl_unlock();
synchronize_rcu();
- skb_array_cleanup(&q->skb_array);
sock_put(&q->sk);
}
@@ -533,10 +532,8 @@ static void macvtap_sock_write_space(struct sock *sk)
static void macvtap_sock_destruct(struct sock *sk)
{
struct macvtap_queue *q = container_of(sk, struct
macvtap_queue, sk);
- struct sk_buff *skb;
- while ((skb = skb_array_consume(&q->skb_array)) != NULL)
- kfree_skb(skb);
+ skb_array_cleanup(&q->skb_array);
}
static int macvtap_open(struct inode *inode, struct file *file)
Re: [PATCH 6/9] remoteproc: core: Add function to append a new resource table entry
Hi Lee,
I just tested your series and found issue with append mechanism.
There is no problem to add resources when working on Linux side, but the
resource table is growing and when copying it at loaded location (ie
overwriting existing prebuilt resource table of firmware), you have an
overflow corrupting part of firmware code.
Moreover firmware code is in general tuned to a feature set. Resource
table is created according to supported features. In most of the cases,
new resource won't be handled by firmware.
Regards,
Loic
On 08/04/2016 11:21 AM, Lee Jones wrote:
A new function now exists to pull in and amend and existing resource
table entry. But what if we wish to provide a new resource? This
function provides functionality to append a brand new resource entry
onto the resource table. All complexity related to shuffling parts
of the table around, providing new offsets and incriminating number
of entries in the resource table's top-level header is taken care of
here.
Signed-off-by: Lee Jones
---
drivers/remoteproc/remoteproc_core.c | 55
1 file changed, 55 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/remoteproc/remoteproc_core.c
index 3318ebd..111350e 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -980,6 +980,61 @@ static int rproc_update_resource_table_entry(struct rproc
*rproc,
return !updated;
}
+static struct resource_table*
+rproc_add_resource_table_entry(struct rproc *rproc,
+ struct rproc_request_resource *request,
+ struct resource_table *old_table, int *tablesz)
+{
+ struct resource_table *table;
+ struct fw_rsc_hdr h;
+ void *new_rsc_loc;
+ void *fw_header_loc;
+ void *start_of_rscs;
+ int new_rsc_offset;
+ int size = *tablesz;
+ int i;
+
+ h.type = request->type;
+
+ new_rsc_offset = size;
+
+ /*
+* Allocate another contiguous chunk of memory, large enough to
+* contain the new, expanded resource table.
+*
+* The +4 is for the extra offset[] element in the top level header
+*/
+ size += sizeof(struct fw_rsc_hdr) + request->size + 4;
+ table = devm_kmemdup(&rproc->dev, old_table, size, GFP_KERNEL);
+ if (!table)
+ return ERR_PTR(-ENOMEM);
+
+ /* Shunt table by 4 Bytes to account for the extra offset[] element */
+ start_of_rscs = (void *)table + table->offset[0];
+ memmove(start_of_rscs + 4,
+ start_of_rscs, new_rsc_offset - table->offset[0]);
+ new_rsc_offset += 4;
+
+ /* Update existing resource entry's offsets */
+ for (i = 0; i < table->num; i++)
+ table->offset[i] += 4;
+
+ /* Update the top level 'resource table' header */
+ table->offset[table->num] = new_rsc_offset;
+ table->num++;
+
+ /* Copy new firmware header into table */
+ fw_header_loc = (void *)table + new_rsc_offset;
+ memcpy(fw_header_loc, &h, sizeof(h));
+
+ /* Copy new resource entry into table */
+ new_rsc_loc = (void *)fw_header_loc + sizeof(h);
+ memcpy(new_rsc_loc, request->resource, request->size);
+
+ *tablesz = size;
+ return table;
+}
+
/*
* take a firmware and boot a remote processor with it.
*/
Re: [PATCH v4 3/4] drm/mediatek: Add gamma correction.
Am Donnerstag, den 28.07.2016, 10:22 +0800 schrieb Bibby Hsieh:
> Add gamma set function to correct brightness values.
> It applies arbitrary mapping curve to compensate the
> incorrect transfer function of the panel.
>
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 31
> +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 10 +
> 4 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 24aa3ba..cbb460a5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
> *crtc,
> }
> if (pending_planes)
> mtk_crtc->pending_planes = true;
> + if (crtc->state->color_mgmt_changed)
> + for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> + mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> }
>
> static const struct drm_crtc_funcs mtk_crtc_funcs = {
> @@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> .reset = mtk_drm_crtc_reset,
> .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> .atomic_destroy_state = mtk_drm_crtc_destroy_state,
> + .gamma_set = drm_atomic_helper_legacy_gamma_set,
> };
>
> static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> @@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> &mtk_crtc->planes[1].base, pipe);
> if (ret < 0)
> goto unprepare;
> -
> + drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
> + drm_helper_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
> + MTK_LUT_SIZE);
I have applied all four patches and rebased onto v4.8-rc1, replacing
drm_helper_crtc_enable_color_mgmt with:
drm_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
true, MTK_LUT_SIZE);
(See https://patchwork.kernel.org/patch/9160987/)
regards
Philipp
Re: [PATCH v4 3/4] drm/mediatek: Add gamma correction.
Am Donnerstag, den 11.08.2016, 10:44 +0300 schrieb Ville Syrjälä:
> On Thu, Aug 11, 2016 at 09:32:59AM +0200, Philipp Zabel wrote:
> > Am Donnerstag, den 28.07.2016, 10:22 +0800 schrieb Bibby Hsieh:
> > > Add gamma set function to correct brightness values.
> > > It applies arbitrary mapping curve to compensate the
> > > incorrect transfer function of the panel.
> > >
> > > Signed-off-by: Bibby Hsieh
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
> > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 31
> > > +++
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 10 +
> > > 4 files changed, 49 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > index 24aa3ba..cbb460a5 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > @@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc
> > > *crtc,
> > > }
> > > if (pending_planes)
> > > mtk_crtc->pending_planes = true;
> > > + if (crtc->state->color_mgmt_changed)
> > > + for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > > + mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], crtc->state);
> > > }
> > >
> > > static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > > @@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > > .reset = mtk_drm_crtc_reset,
> > > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > > .atomic_destroy_state = mtk_drm_crtc_destroy_state,
> > > + .gamma_set = drm_atomic_helper_legacy_gamma_set,
> > > };
> > >
> > > static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > > @@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > > &mtk_crtc->planes[1].base, pipe);
> > > if (ret < 0)
> > > goto unprepare;
> > > -
> > > + drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
> > > + drm_helper_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
> > > + MTK_LUT_SIZE);
> >
> > I have applied all four patches and rebased onto v4.8-rc1, replacing
> > drm_helper_crtc_enable_color_mgmt with:
> >
> > drm_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
> >true, MTK_LUT_SIZE);
>
> BTW that looks wrong (already in the original). AFAICS the patch just
> handled the gamma_lut, not the degamma_lut, so telling you have both
> is not right.
Thanks, so should that be
drm_crtc_enable_color_mgmt(&mtk_crtc->base, 0, false,
MTK_LUT_SIZE);
instead, since we only handle gamma?
regards
Philipp
Re: [PATCH v2 0/7] drm/mediatek: cleaning up and refine
Am Donnerstag, den 04.08.2016, 10:59 +0800 schrieb Bibby Hsieh: > These patches based on 4.7-rc1 to clean up unused function > & variable and use drm core function instead. > > The following patches are needed to cleanly apply on top of v4.7-rc1: > - https://patchwork.kernel.org/patch/8044001/ >(drm: Deal with rotation in drm_plane_helper_check_update()) > - https://patchwork.kernel.org/patch/9248373/ >(drm: Warn about negative sizes when calculating scale factor) > - https://patchwork.kernel.org/patch/9248371/ >(drm: Store clipped src/dst coordinatee in drm_plane_state) > - https://patchwork.kernel.org/patch/9248363/ >(drm/plane-helper: Add drm_plane_helper_check_state()) > - https://patchwork.kernel.org/patch/9248361/ >(drm/mediatek: Use drm_plane_helper_check_state()) > > Bibby Hsieh (2): > drm/mediatek: Use drm_atomic destroy_state helpers > drm/mediatek: Fix mtk_atomic_complete for runtime_pm > > Daniel Kurtz (5): > drm/mediatek: Remove mtk_drm_crtc_check_flush > drm/mediatek: plane: Remove plane zpos/index > drm/mediatek: Remove mtk_drm_plane I have picked up patches 1-5, but not patches 6-7: > drm/mediatek: plane: Merge mtk_plane_enable into > mtk_plane_atomic_update > drm/mediatek: plane: Use FB's format's cpp to compute x offset These two don't apply. Could you please rebase them onto git.pengutronix.de/git/pza/linux.git mediatek-drm/next regards Philipp
Re: [PATCH/RFC] mm, oom: Fix uninitialized ret in task_will_free_mem()
On Wed 03-08-16 22:19:59, Geert Uytterhoeven wrote:
> mm/oom_kill.c: In function ‘task_will_free_mem’:
> mm/oom_kill.c:767: warning: ‘ret’ may be used uninitialized in this
> function
>
> If __task_will_free_mem() is never called inside the for_each_process()
> loop, ret will not be initialized.
>
> Fixes: 1af8bb43269563e4 ("mm, oom: fortify task_will_free_mem()")
> Signed-off-by: Geert Uytterhoeven
Acked-by: Michal Hocko
Thanks for catching that!
> ---
> Untested. I'm not familiar with the code, hence the default value of
> true was deducted from the logic in the loop (return false as soon as
> __task_will_free_mem() has returned false).
> ---
> mm/oom_kill.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 7d0a275df822e9e1..d53a9aa00977cbd0 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -764,7 +764,7 @@ bool task_will_free_mem(struct task_struct *task)
> {
> struct mm_struct *mm = task->mm;
> struct task_struct *p;
> - bool ret;
> + bool ret = true;
>
> /*
>* Skip tasks without mm because it might have passed its exit_mm and
> --
> 1.9.1
>
--
Michal Hocko
SUSE Labs
[PATCH] drm/bridge: dw-hdmi: fix hdmi display lost
hdmi->disabled maybe not match to the real hardware status.
->dw_hdmi_bridge_enable()
hdmi->disabled = false;
-->dw_hdmi_update_power()
if (hdmi->rxsense)
force = DRM_FORCE_ON;
else
force = DRM_FORCE_OFF;
hdmi->rxsense maybe false on bridge enable path, then hdmi->disabled
is false, but actually hardware is power off, they are not match.
So on dw_hdmi_irq, judge the hardware status with hdmi->disabled is wrong.
This bug would cause display lost, unplug/plug can't recovery display.
Cc: Russell King
Cc: Daniel Vetter
Cc: Fabio Estevam
Cc: Liu Ying
Signed-off-by: Mark Yao
---
drivers/gpu/drm/bridge/dw-hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 77ab473..a4fcb47 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1563,7 +1563,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (intr_stat &
(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
mutex_lock(&hdmi->mutex);
- if (!hdmi->disabled && !hdmi->force) {
+ if (!hdmi->bridge_is_on && !hdmi->force) {
/*
* If the RX sense status indicates we're disconnected,
* clear the software rxsense status.
--
1.9.1
[PATCH] SAS: use sas_rphy instead of sas_end_device to obtain address.
Since commit 3f8d6f2a0 ('ses: fix discovery of SATA devices in SAS
enclosures') ses_match_to_enclosure() is calling sas_get_address(),
which is coming from commit bcf508c13385 ('scsi_transport_sas: add
function to get SAS endpoint address'). sas_get_address() itself calls
sas_sdev_to_rdev() which BUG_ON()s if a given scsi_device's rphy is
not a SAS_END_DEVICE.
As SAS Enclosure is a SAS expander device, we really shouldn't tie the
lookup of a SAS address to the SAS End Device but the sas_rphy, which
holds the address information.
Fixes: 3f8d6f2a0 ('ses: fix discovery of SATA devices in SAS enclosures')
Cc: sta...@vger.kernel.org # v4.5+
Signed-off-by: Johannes Thumshirn
---
drivers/scsi/scsi_transport_sas.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_transport_sas.c
b/drivers/scsi/scsi_transport_sas.c
index 3f0ff07..6b6d7b0 100644
--- a/drivers/scsi/scsi_transport_sas.c
+++ b/drivers/scsi/scsi_transport_sas.c
@@ -390,9 +390,9 @@ EXPORT_SYMBOL(sas_remove_host);
*/
u64 sas_get_address(struct scsi_device *sdev)
{
- struct sas_end_device *rdev = sas_sdev_to_rdev(sdev);
+ struct sas_rphy *rphy = target_to_rphy(sdev->sdev_target);
- return rdev->rphy.identify.sas_address;
+ return rphy->identify.sas_address;
}
EXPORT_SYMBOL(sas_get_address);
--
1.8.5.6
Re: [PATCH v4 3/4] drm/mediatek: Add gamma correction.
On Thu, Aug 11, 2016 at 09:51:16AM +0200, Philipp Zabel wrote:
> Am Donnerstag, den 11.08.2016, 10:44 +0300 schrieb Ville Syrjälä:
> > On Thu, Aug 11, 2016 at 09:32:59AM +0200, Philipp Zabel wrote:
> > > Am Donnerstag, den 28.07.2016, 10:22 +0800 schrieb Bibby Hsieh:
> > > > Add gamma set function to correct brightness values.
> > > > It applies arbitrary mapping curve to compensate the
> > > > incorrect transfer function of the panel.
> > > >
> > > > Signed-off-by: Bibby Hsieh
> > > > ---
> > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
> > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 31
> > > > +++
> > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 10 +
> > > > 4 files changed, 49 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > index 24aa3ba..cbb460a5 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > @@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct
> > > > drm_crtc *crtc,
> > > > }
> > > > if (pending_planes)
> > > > mtk_crtc->pending_planes = true;
> > > > + if (crtc->state->color_mgmt_changed)
> > > > + for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > > > + mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i],
> > > > crtc->state);
> > > > }
> > > >
> > > > static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > > > @@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs =
> > > > {
> > > > .reset = mtk_drm_crtc_reset,
> > > > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > > > .atomic_destroy_state = mtk_drm_crtc_destroy_state,
> > > > + .gamma_set = drm_atomic_helper_legacy_gamma_set,
> > > > };
> > > >
> > > > static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > > > @@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > > > &mtk_crtc->planes[1].base, pipe);
> > > > if (ret < 0)
> > > > goto unprepare;
> > > > -
> > > > + drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
> > > > + drm_helper_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
> > > > + MTK_LUT_SIZE);
> > >
> > > I have applied all four patches and rebased onto v4.8-rc1, replacing
> > > drm_helper_crtc_enable_color_mgmt with:
> > >
> > > drm_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
> > > true, MTK_LUT_SIZE);
> >
> > BTW that looks wrong (already in the original). AFAICS the patch just
> > handled the gamma_lut, not the degamma_lut, so telling you have both
> > is not right.
>
> Thanks, so should that be
>drm_crtc_enable_color_mgmt(&mtk_crtc->base, 0, false,
> MTK_LUT_SIZE);
> instead, since we only handle gamma?
Hmm. Yeah, that looks correct since you didn't seem to have "ctm" either.
--
Ville Syrjälä
Intel OTC
Re: [PATCH v3] mac80211: mesh: Add support for HW RC implementation
On Mon, 2016-07-11 at 17:15 +0300, Maxim Altshul wrote: > Mesh HWMP module will be able to rely on the HW > RC algorithm if it exists, for path metric calculations. > > This allows the metric calculation mechanism to calculate > a correct metric, based on PER and last TX rate both via > HW RC algorithm if it exists or via parameters collected > by the SW. > Applied. I decided to put the fix for the sta->uploaded thing into mac80211-next, since there's no driver affected by it now, so please base that patch on this one, if necessary. johannes
Re: [PATCH v5 2/2] Add support for SCT Write Same
On 11 August 2016 at 02:29, Shaun Tancheff wrote: >> >> You are talking about an AF 4Kn drive I suppose? For a 512e drive it >> should be only ~2G. > > I stand corrected. Since all the kernel math is 512 byte sectors you are > absolutely correct and this isn't an issue at all. > > We should report SD_MAX_WS16_BLOCKS when only SCT > is available and 4194240 when TRIM is available. Why would you come up with such decision/conclusion? I thought SD_MAX_WS16_BLOCKS could even be too big for 512e drive (~4G per WRITE SAME command)? If 4194240 (~2G per command) isn't too big for SCT Write Same, then we shoud probably stick with it in both cases (when only SCT Write Same is available / when TRIM is also available) to maintain consistency. Also Maximum Write Same Length should be multiplied by the actual logical sector size of the drive, which would be 4096 in the case of 4Kn drives. (If the kernel isn't doing that, it's simply a bug.) Therefore, if I haven't missed anything, we'll need to divide ATA_MAX_TRIM_RNUM by (logical sector size / 512) anyway, otherwise discard_max_bytes and write_same_max_bytes would overflow with 4Kn drive (i.e. Maximum Write Same Length needs to be <= 0x / 4096). 4Kn SSDs may not be a thing on the market yet, but apparently it's a different story for traditional HDDs, and SCT Write Same isn't only available on SSDs. The division should not change the current behaviour on drives with 512-byte logical sectors. I'll be sending a patch on that.
Re: [PATCH] usb: core: Add runtime resume checking
Hi Peter, On 11 August 2016 at 14:54, Peter Chen wrote: > On Thu, Aug 11, 2016 at 11:08:52AM +0800, Baolin Wang wrote: >> Hi Alan, >> >> On 10 August 2016 at 22:25, Alan Stern wrote: >> > On Wed, 10 Aug 2016, Baolin Wang wrote: >> > >> >> >> >> For example: No slave attached> usb interface runtime suspend >> >> >> >> > usb device runtime suspend -> xhci suspend -> power >> >> >> >> off >> >> >> >> usb controller. After that if the system wants to enter suspend >> >> >> >> state, >> >> >> >> then it also will issue usb_dev_suspend(), then the >> >> >> >> pm_runtime_resume() function (issued in choose_wakeup() function) >> >> >> >> will >> >> >> >> return -ESHUTDOWN due to xhci has been suspend and hardware is not >> >> >> >> accessible. >> >> >> > >> >> >> > Why the controller does not be resumed when the root hub has issued >> >> >> > runtime resume? >> >> >> >> >> >> Because now there is no slave attached, we will not power on usb >> >> >> controller and resume xhci. >> >> >> >> >> > >> >> > I don't know why you set policy like this. Even the controller is >> >> > resumed, it will still be suspended by system suspend. What's more, >> >> > if you disallow it, how can you change your wakeup setting? >> >> > Eg, at runtime suspend, we enable wakeup by default. But for system >> >> > sleep, we disable wakeup by default. >> >> > >> >> > At runtime, if there is no device on the port, even we resumes the >> >> > controller and roohub, it still will be suspended soon. >> >> >> >> For saving power, if there is no slave attached, why we need to power >> >> on usb controller and resume xhci? Especially for mobile device. >> > >> > You need to power-on the USB controller in order to change the wakeup >> > setting. >> >> pm_runtime_resume() function issued in choose_wakeup() can just resume >> usb device, which can not power-on the USB controller and resume xHCI. >> Cause the user won't know you need to power-on usb controller now, >> then how to power-on the USB controller when changing wakeup setting? >> >> > >> >> Moreover the usb device runtime suspend/resume is separate with xhci >> >> suspend/resume, when xhci entered suspend state, only slave attaching >> >> can resume xhci. >> > >> > That's right. Suppose the user wants the system to stay asleep when a >> > slave attaches. But when you suspended the xHCI controller, it was set >> > to wake up when a new slave attaches. So when a slave is attached, the >> > controller will wake up the system. That's bad. >> > >> > If the wakeup setting needs to be changed when the system suspend >> > begins, then you have to power-on the controller to make that change. >> > >> > Given a choice between using a little power or behaving incorrectly, >> > you should choose to use the power. >> >> OK. But that is a real problem. It will pm_runtime_resume() falied >> (issued in choose_wakeup()), cause usb controller has powered-off and >> xHCI controller has suspended and we have no method to notify the user >> to power-on USB controller. Any good suggestion to solve this, Alan >> and Peter? Thanks. >> > > Maybe you can show us the call stack why pm_runtime_resume has failed > at your environment. OK. I try to explain it at below: For example: No slave attached> usb interface runtime suspend > usb device runtime suspend (routine is: usb_suspend_device()--->generic_suspend() --> hcd_bus_suspend()--> xhci_bus_suspend()) -> xhci_ suspend() -> power off usb controller. After that if the system wants to enter suspend state, then it also will issue usb_dev_suspend(), then the pm_runtime_resume() function (issued in choose_wakeup() function) will return -ESHUTDOWN due to xhci has been suspend and hardware is not accessible. We issue the pm_runtime_resume() function routine: usb_resume_device() > generic_resume() > hcd_bus_resume() ---> xhci_bus_resume(), but now xHCI is not accessible due to xhci_suspend() is issued and USB controller is power off when no slave attached. That is why pm_runtime_resume failed. -- Baolin.wang Best Regards
[PATCH] dt-binding: correct the larb port offset defines for mt2701
From: Honghui Zhang larb2 have 23 ports, the LARB3_PORT_OFFSET should be LARB2_PORT_OFFSET plus larb2's port number, it should be 44 instead of 43. Signed-off-by: Honghui Zhang --- include/dt-bindings/memory/mt2701-larb-port.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/dt-bindings/memory/mt2701-larb-port.h b/include/dt-bindings/memory/mt2701-larb-port.h index 78f6678..6764d74 100644 --- a/include/dt-bindings/memory/mt2701-larb-port.h +++ b/include/dt-bindings/memory/mt2701-larb-port.h @@ -26,7 +26,7 @@ #define LARB0_PORT_OFFSET 0 #define LARB1_PORT_OFFSET 11 #define LARB2_PORT_OFFSET 21 -#define LARB3_PORT_OFFSET 43 +#define LARB3_PORT_OFFSET 44 #define MT2701_M4U_ID_LARB0(port) ((port) + LARB0_PORT_OFFSET) #define MT2701_M4U_ID_LARB1(port) ((port) + LARB1_PORT_OFFSET) -- 1.8.1.1.dirty
Re: spin_lock implicit/explicit memory barrier
On Wed, Aug 10, 2016 at 04:29:22PM -0700, Davidlohr Bueso wrote:
> (1) As Manfred suggested, have a patch 1 that fixes the race against mainline
> with the redundant smp_rmb, then apply a second patch that gets rid of it
> for mainline, but only backport the original patch 1 down to 3.12.
I have not followed the thread closely, but this seems like the best
option. Esp. since 726328d92a42 ("locking/spinlock, arch: Update and fix
spin_unlock_wait() implementations") is incomplete, it relies on at
least 6262db7c088b ("powerpc/spinlock: Fix spin_unlock_wait()") to sort
PPC.
Re: [PATCH/RFC] mm, oom: Fix uninitialized ret in task_will_free_mem()
On Thu 04-08-16 14:46:49, Andrew Morton wrote:
> On Thu, 4 Aug 2016 21:28:13 +0900 Tetsuo Handa
> wrote:
>
> > >
> > > Fixes: 1af8bb43269563e4 ("mm, oom: fortify task_will_free_mem()")
> > > Signed-off-by: Geert Uytterhoeven
> > > ---
> > > Untested. I'm not familiar with the code, hence the default value of
> > > true was deducted from the logic in the loop (return false as soon as
> > > __task_will_free_mem() has returned false).
> >
> > I think ret = true is correct. Andrew, please send to linux.git.
>
> task_will_free_mem() is too hard to understand.
>
> We're examining task "A":
>
> : for_each_process(p) {
> : if (!process_shares_mm(p, mm))
> : continue;
> : if (same_thread_group(task, p))
> : continue;
>
> So here, we've found a process `p' which shares A's mm and which does
> not share A's thread group.
>
> : ret = __task_will_free_mem(p);
>
> And here we check to see if killing `p' would free up memory.
>
> : if (!ret)
> : break;
>
> If killing `p' will not free memory then give up the scan of all
> processes because , and we decide that killing `A' will
> not free memory either, because some other task is holding onto
> A's memory anyway.
>
> : }
>
> And if no task is found to be sharing A's mm while not sharing A's
> thread group then fall through and decide to kill A. In which case the
> patch to return `true' is correct.
>
> Correctish?
Yes this is more or less correct. task_will_free_mem is a bit misnomer
but I couldn't come up with something better when reworking it and so
I kept the original name. task_will_free_mem basically says that the
task is dying and we hope it will free some memory so it doesn't make
much sense to send it SIGKILL.
> Maybe. Can we please get some comments in there to
> demystify the decision-making?
Does this help?
---
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 908c097c8b47..ce02db7f8661 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -803,8 +803,9 @@ static bool task_will_free_mem(struct task_struct *task)
return true;
/*
-* This is really pessimistic but we do not have any reliable way
-* to check that external processes share with our mm
+* Make sure that all tasks which share the mm with the given tasks
+* are dying as well to make sure that a) nobody pins its mm and
+* b) the task is also reapable by the oom reaper.
*/
rcu_read_lock();
for_each_process(p) {
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/3] net: stmmac: dwmac-rk: add rk3366 & rk3399 specific data
Hi Roger, Am Donnerstag, 11. August 2016, 15:24:46 schrieb Roger Chen: > Add constants and callback functions for the dwmac on rk3228/rk3229 socs. > As can be seen, the base structure is the same, only registers and the > bits in them moved slightly. > > Signed-off-by: Roger Chen > --- > .../devicetree/bindings/net/rockchip-dwmac.txt | 4 +- > drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 226 > + 2 files changed, 228 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt > b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt index > cccd945..8c066e6 100644 > --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt > +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt > @@ -3,8 +3,8 @@ Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC) > The device node has following properties. > > Required properties: > - - compatible: Can be one of "rockchip,rk3228-gmac", > "rockchip,rk3288-gmac", - > "rockchip,rk3368-gmac" > + - compatible: Can be one of "rockchip,rk3288-gmac", you're dropping the rk3228 here. Otherwise looks fine, so with the compatible list fixed you can add my Reviewed-by: Heiko Stuebner Heiko
Re: [REGRESSION] 362899b ("macvtap: switch to use skb array") causes oops during teardown
On Thu, 11 Aug 2016 15:49:12 +0800
Jason Wang wrote:
> This looks like a use-after-free. Could you pls try the following patch
> to see it if fixes your issue?
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index a38c0da..070e329 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -275,7 +275,6 @@ static void macvtap_put_queue(struct macvtap_queue *q)
> rtnl_unlock();
>
> synchronize_rcu();
> - skb_array_cleanup(&q->skb_array);
> sock_put(&q->sk);
> }
>
> @@ -533,10 +532,8 @@ static void macvtap_sock_write_space(struct sock *sk)
> static void macvtap_sock_destruct(struct sock *sk)
> {
> struct macvtap_queue *q = container_of(sk, struct
> macvtap_queue, sk);
> - struct sk_buff *skb;
>
> - while ((skb = skb_array_consume(&q->skb_array)) != NULL)
> - kfree_skb(skb);
> + skb_array_cleanup(&q->skb_array);
> }
>
> static int macvtap_open(struct inode *inode, struct file *file)
Yes, that change fixes things for me.
Tested-by: Cornelia Huck
Thanks for the quick reply!
Re: [PATCH] pinctrl: qcom: Add generic ssbi and spmi GPIO/MPP bindings
On Mon, Jul 11, 2016 at 9:01 PM, Stephen Boyd wrote: > The drivers don't really need to know which PMIC they're for, so > make a generic binding for them. This alleviates us from updating > the drivers every time a new PMIC comes out. It's still > recommended that we update the binding with new PMIC models and > always specify the specific model for the MPPs and gpios before > the generic compatible string in devicetree, but this at least > cuts down on adding more and more compatible strings to the > drivers until we actually need them. > > Cc: > Acked-by: "Ivan T. Ivanov" > Reviewed-by: Bjorn Andersson > Signed-off-by: Stephen Boyd Patch applied with Rob's ACK. Yours, Linus Walleij
Re: [PATCH -next] ARM: ux500: remove duplicated include from cpu-db8500.c
On Tue, Jul 19, 2016 at 1:27 PM, Wei Yongjun wrote: > From: Wei Yongjun > > Remove duplicated include. > > Signed-off-by: Wei Yongjun Patch applied. Yours, Linus Walleij
Re: [PATCH v13 00/12] support "task_isolation" mode
On Fri, Jul 22, 2016 at 08:50:44AM -0400, Chris Metcalf wrote: > On 7/21/2016 10:20 PM, Christoph Lameter wrote: > >On Thu, 21 Jul 2016, Chris Metcalf wrote: > >>On 7/20/2016 10:04 PM, Christoph Lameter wrote: > >>unstable, and then scheduling work to safely remove that timer. > >>I haven't looked at this code before (in kernel/time/clocksource.c > >>under CONFIG_CLOCKSOURCE_WATCHDOG) since the timers on > >>arm64 and tile aren't unstable. Is it possible to boot your machine > >>with a stable clocksource? > >It already as a stable clocksource. Sorry but that was one of the criteria > >for the server when we ordered them. Could this be clock adjustments? > > We probably need to get clock folks to jump in on this thread! Boot with: tsc=reliable, this disables the watchdog. We (sadly) have to have this thing running on most x86 because TSC, even if initially stable, can do weird things once its running. We have seen: - SMI - hotplug - suspend - multi-socket mess up the TSC, even if it was deemed 'good' at boot time. If you _know_ your TSC to be solid, boot with tsc=reliable and be happy.
Re: [PATCH v2 1/4] gpio: Add AXP209 GPIO driver
On Wed, Jul 20, 2016 at 4:11 PM, Maxime Ripard wrote: > The AXP209 PMIC has a bunch of GPIOs accessible, that are usually used to > control LEDs or backlight. > > Add a driver for them > > Signed-off-by: Maxime Ripard > Acked-by: Rob Herring Patch applied, it's clean and simple. I would suggest the following immediate improvement (send separate patch): Add a .get_direction() callback, I have started to push this for new driver as it gives better userspace experience and overall better control of stuff. Yours, Linus Walleij
Re: [PATCH] usb: core: Add runtime resume checking
On Thu, Aug 11, 2016 at 04:07:21PM +0800, Baolin Wang wrote: > Hi Peter, > > On 11 August 2016 at 14:54, Peter Chen wrote: > > On Thu, Aug 11, 2016 at 11:08:52AM +0800, Baolin Wang wrote: > >> Hi Alan, > >> > >> On 10 August 2016 at 22:25, Alan Stern wrote: > >> > On Wed, 10 Aug 2016, Baolin Wang wrote: > >> > > >> >> >> >> For example: No slave attached> usb interface runtime suspend > >> >> >> >> > usb device runtime suspend -> xhci suspend -> power > >> >> >> >> off > >> >> >> >> usb controller. After that if the system wants to enter suspend > >> >> >> >> state, > >> >> >> >> then it also will issue usb_dev_suspend(), then the > >> >> >> >> pm_runtime_resume() function (issued in choose_wakeup() function) > >> >> >> >> will > >> >> >> >> return -ESHUTDOWN due to xhci has been suspend and hardware is not > >> >> >> >> accessible. > >> >> >> > > >> >> >> > Why the controller does not be resumed when the root hub has issued > >> >> >> > runtime resume? > >> >> >> > >> >> >> Because now there is no slave attached, we will not power on usb > >> >> >> controller and resume xhci. > >> >> >> > >> >> > > >> >> > I don't know why you set policy like this. Even the controller is > >> >> > resumed, it will still be suspended by system suspend. What's more, > >> >> > if you disallow it, how can you change your wakeup setting? > >> >> > Eg, at runtime suspend, we enable wakeup by default. But for system > >> >> > sleep, we disable wakeup by default. > >> >> > > >> >> > At runtime, if there is no device on the port, even we resumes the > >> >> > controller and roohub, it still will be suspended soon. > >> >> > >> >> For saving power, if there is no slave attached, why we need to power > >> >> on usb controller and resume xhci? Especially for mobile device. > >> > > >> > You need to power-on the USB controller in order to change the wakeup > >> > setting. > >> > >> pm_runtime_resume() function issued in choose_wakeup() can just resume > >> usb device, which can not power-on the USB controller and resume xHCI. > >> Cause the user won't know you need to power-on usb controller now, > >> then how to power-on the USB controller when changing wakeup setting? > >> > >> > > >> >> Moreover the usb device runtime suspend/resume is separate with xhci > >> >> suspend/resume, when xhci entered suspend state, only slave attaching > >> >> can resume xhci. > >> > > >> > That's right. Suppose the user wants the system to stay asleep when a > >> > slave attaches. But when you suspended the xHCI controller, it was set > >> > to wake up when a new slave attaches. So when a slave is attached, the > >> > controller will wake up the system. That's bad. > >> > > >> > If the wakeup setting needs to be changed when the system suspend > >> > begins, then you have to power-on the controller to make that change. > >> > > >> > Given a choice between using a little power or behaving incorrectly, > >> > you should choose to use the power. > >> > >> OK. But that is a real problem. It will pm_runtime_resume() falied > >> (issued in choose_wakeup()), cause usb controller has powered-off and > >> xHCI controller has suspended and we have no method to notify the user > >> to power-on USB controller. Any good suggestion to solve this, Alan > >> and Peter? Thanks. > >> > > > > Maybe you can show us the call stack why pm_runtime_resume has failed > > at your environment. > > OK. I try to explain it at below: > > For example: No slave attached> usb interface runtime suspend > > usb device runtime suspend (routine is: > usb_suspend_device()--->generic_suspend() --> hcd_bus_suspend()--> > xhci_bus_suspend()) -> xhci_ suspend() -> power off usb > controller. After that if the system wants to enter suspend state, > then it also will issue usb_dev_suspend(), then the > pm_runtime_resume() function (issued in choose_wakeup() function) will > return -ESHUTDOWN due to xhci has been suspend and hardware is not accessible. > > We issue the pm_runtime_resume() function routine: usb_resume_device() > > generic_resume() > hcd_bus_resume() ---> xhci_bus_resume(), > but now xHCI is not accessible due to xhci_suspend() is issued and USB > controller is power off when no slave attached. That is why > pm_runtime_resume failed. > What host controller driver you are using? Assume you are using xhci-plat.c. The problem for you is this driver does not implement runtime pm operations, so the flag HCD_FLAG_HW_ACCESSIBLE is not set. Maybe Robert's patch is a good start for you [1] [1] http://www.spinics.net/lists/linux-usb/msg144602.html -- Best Regards, Peter Chen
Re: [PATCH] drm/bridge: dw-hdmi: fix hdmi display lost
On Thu, Aug 11, 2016 at 03:54:03PM +0800, Mark Yao wrote: > hdmi->disabled maybe not match to the real hardware status. > > ->dw_hdmi_bridge_enable() > hdmi->disabled = false; > -->dw_hdmi_update_power() >if (hdmi->rxsense) >force = DRM_FORCE_ON; >else >force = DRM_FORCE_OFF; > > hdmi->rxsense maybe false on bridge enable path, then hdmi->disabled > is false, but actually hardware is power off, they are not match. ... which is correct. If rxsense is false, it means there is nothing plugged in, so we don't power the hardware up until something _is_ plugged in. When something is plugged in, we get the HPD and RXSENSE events, which will cause dw_hdmi_update_power() to be called. hdmi->disabled is merely a bit mask of things that would cause us to want to avoid powering the hardware up when rxsense becomes true. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH 2/4] usb: gadget: f_midi: defaults buflen sizes to 512
Hi Balbi, On 10/08/16 12:25, Felipe Balbi wrote: > > Hi, > > "Felipe F. Tonello" writes: >> 512 is the value used by wMaxPacketSize, as specified by the USB Spec. This > > this is only true for HS :-) FS and SS use different sizes. Do you want > to use 1024 (SS maxp) by default instead? Then all speeds will have this > working out just fine. That's true, altough I've never seen a FS or SS device with MIDI gadget, they are all 1.1 or 2.0 max. Nevertheless, your suggestion really makes sense since it will work in any situation. -- Felipe 0x92698E6A.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH v3 0/8] scpi: Add SCPI registry to handle legacy protocol
Hi Frank, On 08/10/2016 12:19 PM, Frank Wang wrote: > Hi Neil, > > On 2016/8/9 18:29, Neil Armstrong wrote: [...] >> >> Changes since RFC v2 at https://lkml.org/lkml/2016/6/21/324 : >> - Moved MHU to a separate patchset posted at >> http://lkml.kernel.org/r/1470732737-18391-1-git-send-email-narmstrong@baylib >> re.com >> - Added a vendor send_message callback into scpi_ops to implement vendor >> commands >> - Implement EXT commands on arm scpi as vendor send_command >> - Added Rockchip variant mailbox handling > > Two questions, > > 1. For legacy_scpi, I saw you have implemented .vendor_send_message api, > however, it seems that does not distinguish standard and extended command, so > it may be misleading if the vendor send out a non-standard command from their > own driver module. Actually, the vendor_send_message is for non-standard command, and since it's vendor code is should be specific to the platform and won't have any effect on other platforms. DDR and other rockchip specific command shoudl go through this API. The legacy_scpi code does not distinguish standard and extended command since nothing was made into the protocol for this. > > 2. For arm_scpi, it have already distinguished standard and extended command, > but unfortunately, there was no rockchip_scpi_xfer structure something like > in legacy_scpi driver, so if some vendor (just like Rockchip :-)) wanna > switch the driver from legacy_scpi to arm_scpi, maybe this is a bit problem, > how do you think? Yes, it could be added the same way it was added to legacy_scpi, Sudeep made the assumption it would work with any mailbox controller, but since the mailbox framework does not make any assumption about the data type between the controller and the client, such adaptation is necessary. Neil > > BR. > Frank > >> Initial RFC discution tread can be found at >> https://lkml.org/lkml/2016/5/26/111 >> >> @Sudeep: I know you wished I merged the legacy into the arm_scpi, but can >> you take a look at the vendor extension and how I implemented the rockchip >> mailbox handling ? >> >> Neil Armstrong (8): >>firmware: Add a SCPI registry to handle multiple implementations >>firmware: scpi: Switch arm_scpi to use new registry >>scpi: Add vendor_send_message to enable access to vendor commands >>firmware: arm_scpi: Enable vendor_send_message as ext commands >>firmware: Add legacy SCPI protocol driver >>dt-bindings: arm: Update arm,scpi bindings with Meson GXBB SCPI >>ARM64: dts: meson-gxbb: Add SRAM node >>ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes >> >> Documentation/devicetree/bindings/arm/arm,scpi.txt | 8 +- >> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi| 45 ++ >> drivers/firmware/Kconfig | 24 + >> drivers/firmware/Makefile | 2 + >> drivers/firmware/arm_scpi.c| 40 +- >> drivers/firmware/legacy_scpi.c | 710 >> + >> drivers/firmware/scpi.c| 94 +++ >> include/linux/scpi_protocol.h | 20 +- >> 8 files changed, 928 insertions(+), 15 deletions(-) >> create mode 100644 drivers/firmware/legacy_scpi.c >> create mode 100644 drivers/firmware/scpi.c >> > >
Re: [PATCH] watchdog: core: Fix devres_alloc() allocation size
On 08/10/2016 07:34 AM, Guenter Roeck wrote:
> Coverity reports:
>
> Passing argument 152UL /* sizeof (*wdd) */ to function __devres_alloc_node
> and then casting the return value to struct watchdog_device ** is
> suspicious.
>
> Allocation size needs to be sizeof(*rcwdd), not sizeof(*wdd).
>
> Fixes: 83fbae5a148c ("watchdog: Add a device managed API for ...")
> Cc: Neil Armstrong
> Signed-off-by: Guenter Roeck
> ---
> drivers/watchdog/watchdog_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/watchdog_core.c
> b/drivers/watchdog/watchdog_core.c
> index 6abb83cd7681..74265b2f806c 100644
> --- a/drivers/watchdog/watchdog_core.c
> +++ b/drivers/watchdog/watchdog_core.c
> @@ -349,7 +349,7 @@ int devm_watchdog_register_device(struct device *dev,
> struct watchdog_device **rcwdd;
> int ret;
>
> - rcwdd = devres_alloc(devm_watchdog_unregister_device, sizeof(*wdd),
> + rcwdd = devres_alloc(devm_watchdog_unregister_device, sizeof(*rcwdd),
>GFP_KERNEL);
> if (!rcwdd)
> return -ENOMEM;
>
My bad...
Acked-by: Neil Armstrong
Re: [Patch v3 2/2] x86/acpi: Remove the repeated lapic address override entry parsing
* Baoquan He wrote: > On 08/10/16 at 04:02pm, Ingo Molnar wrote: > > > > * Baoquan He wrote: > > > > > ACPI MADT has a 32-bit field providing lapic address at which > > > each processor can access its lapic information. MADT also contains > > > an optional entry to provide a 64-bit address to override the 32-bit > > > one. However the current code does the lapic address override entry > > > parsing twice. One is in early_acpi_boot_init() because AMD NUMA need > > > get boot_cpu_id earlier. The other is in acpi_boot_init() which parses > > > all MADT entries. > > > > > > So in this patch remove the repeated code in the 2nd part. Meanwhile > > > print lapic override entry information like other MADT entry, this > > > will be added to boot log. > > > > it is not at all clear to me from this changelog whether the change is > > supposed to > > change anything. If not then please spell it out explicitly: > > > > "This patch is not supposed to change any behavior." > > I don't know if adding new information to boot log can be seen as > behavior change. If lapic override entry exist, the code change will > add one line of message to boot log: > > LAPIC_ADDR_OVR (address[0x]) > > If this is not behavior change, I will add the sentence you suggested. Yeah, you can write it: "This patch is not supposed to change any runtime behavior, other than improving kernel messages." Thanks, Ingo
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons
On 08/08/16 22:48, Linus Walleij wrote:
> On Sat, Aug 6, 2016 at 1:45 AM, John Stultz wrote:
>
>> @@ -614,7 +615,11 @@ unsigned int irq_create_fwspec_mapping(struct
>> irq_fwspec *fwspec)
>> * it now and return the interrupt number.
>> */
>> if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
>> - irq_set_irq_type(virq, type);
>> + irq_data = irq_get_irq_data(virq);
>> + if (!irq_data)
>> + return 0;
>> +
>> + irqd_set_trigger_type(irq_data, type);
>> return virq;
>> }
>>
>> If I revert just that, it works again.
>
> This makes my platform work too.
> Tested-by: Linus Walleij
Hmmm. I'm now booting your kernel on the APQ8060, and reverting this
hunk doesn't fix it for me. I'm confused...
The interesting part is this:
109: 10 0 msmgpio 88 Level (null)
which shows that the cascade interrupt has been disabled after 10
unhandled interrupts. Somehow, this screams "misconfiguration"...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH 1/4] usb: gadget: f_midi: fixed endianness when using wMaxPacketSize
Hi Balbi, On 10/08/16 12:24, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> On 26 July 2016 at 07:15, Felipe F. Tonello wrote: >>> USB spec specifies wMaxPacketSize to be little endian (as other properties), >>> so when using this variable in the driver we should convert to the current >>> CPU endianness if necessary. >>> >>> Signed-off-by: Felipe F. Tonello >>> --- >>> drivers/usb/gadget/function/f_midi.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/usb/gadget/function/f_midi.c >>> b/drivers/usb/gadget/function/f_midi.c >>> index 58fc199a18ec..a83d852b1da5 100644 >>> --- a/drivers/usb/gadget/function/f_midi.c >>> +++ b/drivers/usb/gadget/function/f_midi.c >>> @@ -362,7 +362,7 @@ static int f_midi_set_alt(struct usb_function *f, >>> unsigned intf, unsigned alt) >>> struct usb_request *req = >>> midi_alloc_ep_req(midi->out_ep, >>> max_t(unsigned, midi->buflen, >>> - bulk_out_desc.wMaxPacketSize)); >>> + >>> le16_to_cpu(bulk_out_desc.wMaxPacketSize))); >> >> I think here we should use usb_ep_align_maybe() function instead of >> max_t() to handle 'quirk_ep_out_aligned_size' quirk, please see the >> patch I've send out: https://lkml.org/lkml/2016/7/12/106 > > agree, if usb_ep_align_maybe() has a bug with endianness, let's fix it > since there are other gadgets using usb_ep_align_maybe() > Can you take a look at v4 of this patchset, please? It's the latest stuff I have sent. -- Felipe 0x92698E6A.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [PATCH] i2c: i2c-mv64xxx: add suspend/resume support
Hi,
I just wanted to kindly remind about this patch.
Best regards,
Grzegorz
2016-07-21 12:39 GMT+02:00 Grzegorz Jaszczyk :
> There is no need to implement subroutine for suspend since there is no
> data to store before suspending.
>
> Signed-off-by: Grzegorz Jaszczyk
> ---
> drivers/i2c/busses/i2c-mv64xxx.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c
> b/drivers/i2c/busses/i2c-mv64xxx.c
> index b4dec08..dc048e7 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -977,12 +977,24 @@ mv64xxx_i2c_remove(struct platform_device *dev)
> return 0;
> }
>
> +static int mv64xxx_i2c_resume(struct device *dev)
> +{
> + struct mv64xxx_i2c_data *drv_data = dev_get_drvdata(dev);
> +
> + mv64xxx_i2c_hw_init(drv_data);
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(mv64xxx_i2c_pm_ops, NULL, mv64xxx_i2c_resume);
> +
> static struct platform_driver mv64xxx_i2c_driver = {
> .probe = mv64xxx_i2c_probe,
> .remove = mv64xxx_i2c_remove,
> .driver = {
> .name = MV64XXX_I2C_CTLR_NAME,
> .of_match_table = mv64xxx_i2c_of_match_table,
> + .pm = &mv64xxx_i2c_pm_ops,
> },
> };
>
> --
> 1.8.3.1
>
Re: [PATCH] thermal: armada: add support for suspend/resume
Hi,
I just wanted to kindly remind about this patch.
Best regards,
Grzegorz
2016-07-21 12:43 GMT+02:00 Grzegorz Jaszczyk :
> There is no need to implement subroutine for suspend since there is no
> data to store before suspending.
>
> Signed-off-by: Grzegorz Jaszczyk
> ---
> drivers/thermal/armada_thermal.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/thermal/armada_thermal.c
> b/drivers/thermal/armada_thermal.c
> index ae75328..65f9838 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -304,12 +304,26 @@ static int armada_thermal_exit(struct platform_device
> *pdev)
> return 0;
> }
>
> +static int armada_thermal_resume(struct device *dev)
> +{
> + struct thermal_zone_device *thermal =
> + dev_get_drvdata(dev);
> + struct armada_thermal_priv *priv = thermal->devdata;
> +
> + priv->data->init_sensor(to_platform_device(dev), priv);
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(armada_thermal_pm_ops, NULL, armada_thermal_resume);
> +
> static struct platform_driver armada_thermal_driver = {
> .probe = armada_thermal_probe,
> .remove = armada_thermal_exit,
> .driver = {
> .name = "armada_thermal",
> .of_match_table = armada_thermal_id_table,
> + .pm = &armada_thermal_pm_ops,
> },
> };
>
> --
> 1.8.3.1
>
Re: clocksource_watchdog causing scheduling of timers every second (was [v13] support "task_isolation" mode)
On Thu, Aug 11, 2016 at 12:16:58AM +0200, Frederic Weisbecker wrote: > I had similar issues, this seems to happen when the tsc is considered not > reliable > (which doesn't necessarily mean unstable. I think it has to do with some x86 > CPU feature > flag). Right, as per the other email, in general we cannot know/assume the TSC to be working as intended :/ > IIRC, this _has_ to execute on all online CPUs because every TSCs of running > CPUs > are concerned. With modern Intel we could run it on one CPU per package I think, but at the same time, too much in NOHZ_FULL assumes the TSC is indeed sane so it doesn't make sense to me to keep the watchdog running, when it triggers it would also have to kill all NOHZ_FULL stuff, which would probably bring the entire machine down.. Arguably we should issue a boot time warning if NOHZ_FULL is configured and the TSC watchdog is running. > I personally override that with passing the tsc=reliable kernel > parameter. Of course use it at your own risk. Yes, that is (sadly) our only option. Manually assert our hardware is solid under the intended workload and then manually disabling the watchdog.
Re: [PATCH 02/12] pinctrl: Add core pinctrl support for Aspeed SoCs
On Wed, Jul 20, 2016 at 7:58 AM, Andrew Jeffery wrote:
> --- a/arch/arm/mach-aspeed/Kconfig
> +++ b/arch/arm/mach-aspeed/Kconfig
> @@ -5,6 +5,7 @@ menuconfig ARCH_ASPEED
> select WATCHDOG
> select ASPEED_WATCHDOG
> select MOXART_TIMER
> + select PINCTRL
> help
> Say Y here if you want to run your kernel on an ASpeed BMC SoC.
This needs to be a separate patch sent to the ARM SoC tree.
I don't like to merge patches to other subsystems if it can be
avoided.
> +static inline void aspeed_sig_desc_print_val(
> + const struct aspeed_sig_desc *desc, bool enable, u32 rv)
> +{
> +#if defined(CONFIG_DEBUG_PINCTRL)
> + pr_debug("SCU%x[0x%08x]=0x%x, got 0x%x from 0x%08x\n", desc->reg,
> + desc->mask, enable ? desc->enable : desc->disable,
> + (rv & desc->mask) >> __ffs(desc->mask), rv);
> +#endif
> +}
You can just use pr_debug(). CONFIG_DEBUG_PINCTRL enables
DEBUG_KERNEL which activates debug prints so this is a truism.
> +static bool aspeed_sig_desc_eval(const struct aspeed_sig_desc *desc,
> + bool enabled, struct regmap *map)
> +static bool aspeed_sig_expr_eval(const struct aspeed_sig_expr *expr,
> + bool enabled, struct regmap *map)
These need kerneldoc too, they are kind of hard to understand.
> +static bool aspeed_gpio_in_exprs(const struct aspeed_sig_expr **exprs)
> +{
> + if (!exprs)
> + return false;
> +
> + while (*exprs) {
> + if (strncmp((*exprs)->signal, "GPIO", 4) == 0)
> + return true;
This looks a bit fragile and hard to debug. Do you have some better
idea of how to do this but not resort to string comparison?
Apart from that it looks pretty alright, complex but such is life
with complex hardware.
Yours,
Linus Walleij
[PATCH v2 06/10] clk: qcom: Add support for PLLs supporting dynamic reprogramming
Some PLLs can support dynamic reprogramming, which means just a L value
change is whats needed to change the PLL frequency without having to
explicitly enable/disable or bypass/re-lock the PLL.
Add support for such PLLs' initial configuration and the ops needed to
support the dynamic reprogramming thereafter.
Signed-off-by: Rajendra Nayak
---
drivers/clk/qcom/clk-pll.c | 106 +
drivers/clk/qcom/clk-pll.h | 9 +++-
2 files changed, 114 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/clk-pll.c b/drivers/clk/qcom/clk-pll.c
index b463432..13d3f64 100644
--- a/drivers/clk/qcom/clk-pll.c
+++ b/drivers/clk/qcom/clk-pll.c
@@ -32,6 +32,7 @@
#define PLL_BIAS_COUNT_SHIFT 14
#define PLL_BIAS_COUNT_MASK0x3f
#define PLL_VOTE_FSM_ENA BIT(20)
+#define PLL_DYN_FSM_ENABIT(20)
#define PLL_VOTE_FSM_RESET BIT(21)
static int clk_pll_enable(struct clk_hw *hw)
@@ -248,6 +249,19 @@ clk_pll_set_fsm_mode(struct clk_pll *pll, struct regmap
*regmap, u8 lock_count)
PLL_VOTE_FSM_ENA);
}
+static void
+clk_pll_set_dynamic_fsm_mode(struct clk_pll *pll, struct regmap *regmap)
+{
+ u32 val;
+ u32 mask;
+
+ mask = PLL_BIAS_COUNT_MASK | PLL_DYN_FSM_ENA;
+ val = 6 << PLL_BIAS_COUNT_SHIFT;
+ val |= PLL_DYN_FSM_ENA;
+
+ regmap_update_bits(regmap, pll->mode_reg, mask, val);
+}
+
static void clk_pll_configure(struct clk_pll *pll, struct regmap *regmap,
const struct pll_config *config)
{
@@ -299,6 +313,21 @@ void clk_pll_configure_sr_hpm_lp(struct clk_pll *pll,
struct regmap *regmap,
}
EXPORT_SYMBOL_GPL(clk_pll_configure_sr_hpm_lp);
+void clk_pll_configure_dynamic(struct clk_pll *pll, struct regmap *regmap,
+ const struct pll_config *config)
+{
+ u32 config_ctl_reg = pll->config_ctl_reg;
+ u32 config_ctl_hi_reg = pll->config_ctl_reg + 4;
+
+ clk_pll_configure(pll, regmap, config);
+
+ regmap_write(regmap, config_ctl_reg, config->config_ctl_val);
+ regmap_write(regmap, config_ctl_hi_reg, config->config_ctl_hi_val);
+
+ clk_pll_set_dynamic_fsm_mode(pll, regmap);
+}
+EXPORT_SYMBOL_GPL(clk_pll_configure_dynamic);
+
static int clk_pll_sr2_enable(struct clk_hw *hw)
{
struct clk_pll *pll = to_clk_pll(hw);
@@ -373,3 +402,80 @@ const struct clk_ops clk_pll_sr2_ops = {
.determine_rate = clk_pll_determine_rate,
};
EXPORT_SYMBOL_GPL(clk_pll_sr2_ops);
+
+static int clk_pll_dynamic_enable(struct clk_hw *hw)
+{
+ struct clk_pll *pll = to_clk_pll(hw);
+
+ /* Wait for 50us explicitly to avoid transient locks */
+ udelay(50);
+
+ return wait_for_pll(pll);
+};
+
+static void clk_pll_dynamic_disable(struct clk_hw *hw)
+{
+ /* 8 reference clock cycle delay mandated by the HPG */
+ udelay(1);
+};
+
+static unsigned long
+clk_pll_dynamic_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+ u32 l_val;
+ int ret;
+
+ struct clk_pll *pll = to_clk_pll(hw);
+
+ ret = regmap_read(pll->clkr.regmap, pll->l_reg, &l_val);
+ if (ret)
+ return ret;
+
+ return l_val * parent_rate;
+};
+
+static int
+clk_pll_dynamic_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
+{
+ struct clk_pll *pll = to_clk_pll(hw);
+ const struct pll_freq_tbl *f;
+
+ f = find_freq(pll->freq_tbl, req->rate);
+ if (!f)
+ req->rate = DIV_ROUND_UP(req->rate, req->best_parent_rate)
+ * req->best_parent_rate;
+ else
+ req->rate = f->freq;
+
+ if (req->rate < pll->min_rate)
+ req->rate = pll->min_rate;
+ else if (req->rate > pll->max_rate)
+ req->rate = pll->max_rate;
+
+ return 0;
+}
+
+static int
+clk_pll_dynamic_set_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long prate)
+{
+ u32 l_val;
+ struct clk_pll *pll = to_clk_pll(hw);
+
+ if ((rate < pll->min_rate) || (rate > pll->max_rate) || !prate)
+ return -EINVAL;
+
+ l_val = rate / prate;
+ regmap_write(pll->clkr.regmap, pll->l_reg, l_val);
+
+ return 0;
+}
+
+const struct clk_ops clk_pll_dynamic_ops = {
+ .enable = clk_pll_dynamic_enable,
+ .disable = clk_pll_dynamic_disable,
+ .set_rate = clk_pll_dynamic_set_rate,
+ .recalc_rate = clk_pll_dynamic_recalc_rate,
+ .determine_rate = clk_pll_dynamic_determine_rate,
+};
+EXPORT_SYMBOL_GPL(clk_pll_dynamic_ops);
diff --git a/drivers/clk/qcom/clk-pll.h b/drivers/clk/qcom/clk-pll.h
index dbe22a9..627588f 100644
--- a/drivers/clk/qcom/clk-pll.h
+++ b/drivers/clk/qcom/clk-pll.h
@@ -52,9 +52,12 @@ struct clk_pll {
u32 config_reg;
u32 mode_reg;
u32 status_reg;
+ u32 config_ctl_reg;
u8 status_bit;
u8 post_div_width;
u8 post_div_shift;
+
[PATCH v2 05/10] clk: qcom: Add support for PLLs with early output
Some PLLs can have an additional early output (apart from
the main and aux outputs). Add support for the PLL driver
so it can be used to initialize/configure the early output
Signed-off-by: Rajendra Nayak
---
drivers/clk/qcom/clk-pll.c | 2 ++
drivers/clk/qcom/clk-pll.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/clk/qcom/clk-pll.c b/drivers/clk/qcom/clk-pll.c
index 08d2fa2..b463432 100644
--- a/drivers/clk/qcom/clk-pll.c
+++ b/drivers/clk/qcom/clk-pll.c
@@ -268,6 +268,7 @@ static void clk_pll_configure(struct clk_pll *pll, struct
regmap *regmap,
val |= config->mn_ena_mask;
val |= config->main_output_mask;
val |= config->aux_output_mask;
+ val |= config->early_output_mask;
mask = config->vco_mask;
mask |= config->pre_div_mask;
@@ -275,6 +276,7 @@ static void clk_pll_configure(struct clk_pll *pll, struct
regmap *regmap,
mask |= config->mn_ena_mask;
mask |= config->main_output_mask;
mask |= config->aux_output_mask;
+ mask |= config->early_output_mask;
regmap_update_bits(regmap, pll->config_reg, mask, val);
}
diff --git a/drivers/clk/qcom/clk-pll.h b/drivers/clk/qcom/clk-pll.h
index 083727e..dbe22a9 100644
--- a/drivers/clk/qcom/clk-pll.h
+++ b/drivers/clk/qcom/clk-pll.h
@@ -81,6 +81,7 @@ struct pll_config {
u32 mn_ena_mask;
u32 main_output_mask;
u32 aux_output_mask;
+ u32 early_output_mask;
};
void clk_pll_configure_sr(struct clk_pll *pll, struct regmap *regmap,
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2 09/10] clk: qcom: Add .is_enabled ops for clk-alpha-pll
This would be useful in subsequent patches when the .set_rate operation
would need to identify if the PLL is actually enabled
Signed-off-by: Rajendra Nayak
---
drivers/clk/qcom/clk-alpha-pll.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 854487e..2184dc1 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -198,6 +198,23 @@ static void clk_alpha_pll_hwfsm_disable(struct clk_hw *hw)
wait_for_pll_disable(pll, PLL_ACTIVE_FLAG);
}
+static int clk_alpha_pll_is_enabled(struct clk_hw *hw)
+{
+ int ret;
+ u32 val, off;
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+
+ off = pll->offset;
+ ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, &val);
+ if (ret)
+ return ret;
+
+ if (val & PLL_LOCK_DET)
+ return 1;
+ else
+ return 0;
+}
+
static int clk_alpha_pll_enable(struct clk_hw *hw)
{
int ret;
@@ -398,6 +415,7 @@ static long clk_alpha_pll_round_rate(struct clk_hw *hw,
unsigned long rate,
const struct clk_ops clk_alpha_pll_ops = {
.enable = clk_alpha_pll_enable,
.disable = clk_alpha_pll_disable,
+ .is_enabled = clk_alpha_pll_is_enabled,
.recalc_rate = clk_alpha_pll_recalc_rate,
.round_rate = clk_alpha_pll_round_rate,
.set_rate = clk_alpha_pll_set_rate,
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2 08/10] clk: qcom: Cleanup some macro defs
From: Taniya Das Move all '# define XYZ' to '#define XYZ' Signed-off-by: Taniya Das Signed-off-by: Rajendra Nayak --- drivers/clk/qcom/clk-alpha-pll.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c index e8f3505..854487e 100644 --- a/drivers/clk/qcom/clk-alpha-pll.c +++ b/drivers/clk/qcom/clk-alpha-pll.c @@ -21,28 +21,28 @@ #include "common.h" #define PLL_MODE 0x00 -# define PLL_OUTCTRL BIT(0) -# define PLL_BYPASSNL BIT(1) -# define PLL_RESET_N BIT(2) -# define PLL_LOCK_COUNT_SHIFT 8 -# define PLL_LOCK_COUNT_MASK 0x3f -# define PLL_BIAS_COUNT_SHIFT 14 -# define PLL_BIAS_COUNT_MASK 0x3f -# define PLL_VOTE_FSM_ENA BIT(20) -# define PLL_VOTE_FSM_RESETBIT(21) -# define PLL_ACTIVE_FLAG BIT(30) -# define PLL_LOCK_DET BIT(31) +#define PLL_OUTCTRLBIT(0) +#define PLL_BYPASSNL BIT(1) +#define PLL_RESET_NBIT(2) +#define PLL_LOCK_COUNT_SHIFT 8 +#define PLL_LOCK_COUNT_MASK0x3f +#define PLL_BIAS_COUNT_SHIFT 14 +#define PLL_BIAS_COUNT_MASK0x3f +#define PLL_VOTE_FSM_ENA BIT(20) +#define PLL_VOTE_FSM_RESET BIT(21) +#define PLL_ACTIVE_FLAGBIT(30) +#define PLL_LOCK_DET BIT(31) #define PLL_L_VAL 0x04 #define PLL_ALPHA_VAL 0x08 #define PLL_ALPHA_VAL_U0x0c #define PLL_USER_CTL 0x10 -# define PLL_POST_DIV_SHIFT8 -# define PLL_POST_DIV_MASK 0xf -# define PLL_ALPHA_EN BIT(24) -# define PLL_VCO_SHIFT 20 -# define PLL_VCO_MASK 0x3 +#define PLL_POST_DIV_SHIFT 8 +#define PLL_POST_DIV_MASK 0xf +#define PLL_ALPHA_EN BIT(24) +#define PLL_VCO_SHIFT 20 +#define PLL_VCO_MASK 0x3 #define PLL_USER_CTL_U 0x14 -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2 10/10] clk: qcom: Fix .set_rate to handle alpha PLLs w/wo dynamic update
From: Taniya Das
Alpha PLLs which do not support dynamic update feature
need to be explicitly disabled before a rate change. The ones which do
support dynamic update don't have to be disabled but need to follow a update
sequence (as implemented by clk_alpha_pll_dynamic_update() in the patch).
They also need the PLL_HW_LOGIC_BYPASS bit set at init.
Signed-off-by: Taniya Das
Signed-off-by: Rajendra Nayak
---
drivers/clk/qcom/clk-alpha-pll.c | 48
drivers/clk/qcom/clk-alpha-pll.h | 1 +
2 files changed, 49 insertions(+)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 2184dc1..68c90f3 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -113,6 +113,11 @@ static int wait_for_pll_offline(struct clk_alpha_pll *pll,
u32 mask)
#define PLL_OFFLINE_ACKBIT(28)
#define PLL_ACTIVE_FLAGBIT(30)
+/* alpha pll with dynamic update support */
+#define PLL_UPDATE BIT(22)
+#define PLL_HW_LOGIC_BYPASSBIT(23)
+#define PLL_ACK_LATCH BIT(29)
+
void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
const struct alpha_pll_config *config)
{
@@ -138,6 +143,37 @@ void clk_alpha_pll_configure(struct clk_alpha_pll *pll,
struct regmap *regmap,
if (pll->flags & SUPPORTS_VOTE_FSM)
qcom_pll_set_fsm_mode(regmap, pll->offset + PLL_MODE, 6, 0);
+ if (pll->flags & SUPPORTS_DYNAMIC_UPDATE)
+ regmap_update_bits(regmap, pll->offset + PLL_MODE,
+ PLL_HW_LOGIC_BYPASS,
+ PLL_HW_LOGIC_BYPASS);
+}
+
+static int clk_alpha_pll_dynamic_update(struct clk_alpha_pll *pll)
+{
+ u32 val;
+
+ /* Latch the input to the PLL */
+ regmap_update_bits(pll->clkr.regmap, pll->offset + PLL_MODE,
+ PLL_UPDATE, PLL_UPDATE);
+
+ /* Wait for 2 reference cycle before checking ACK bit */
+ udelay(1);
+
+ regmap_read(pll->clkr.regmap, pll->offset + PLL_MODE, &val);
+ if (!(val & PLL_ACK_LATCH)) {
+ WARN(1, "PLL latch failed. Output may be unstable!\n");
+ return -EINVAL;
+ }
+
+ /* Return latch input to 0 */
+ regmap_update_bits(pll->clkr.regmap, pll->offset + PLL_MODE,
+ PLL_UPDATE, 0);
+
+ /* Wait for PLL output to stabilize */
+ udelay(100);
+
+ return 0;
}
static int clk_alpha_pll_hwfsm_enable(struct clk_hw *hw)
@@ -366,6 +402,7 @@ clk_alpha_pll_recalc_rate(struct clk_hw *hw, unsigned long
parent_rate)
static int clk_alpha_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long prate)
{
+ int enabled;
struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
const struct pll_vco *vco;
u32 l, off = pll->offset;
@@ -378,6 +415,11 @@ static int clk_alpha_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
return -EINVAL;
}
+ enabled = hw->init->ops->is_enabled(hw);
+
+ if (!(pll->flags & SUPPORTS_DYNAMIC_UPDATE) && enabled)
+ hw->init->ops->disable(hw);
+
a <<= (ALPHA_REG_BITWIDTH - ALPHA_BITWIDTH);
regmap_write(pll->clkr.regmap, off + PLL_L_VAL, l);
@@ -391,6 +433,12 @@ static int clk_alpha_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
regmap_update_bits(pll->clkr.regmap, off + PLL_USER_CTL, PLL_ALPHA_EN,
PLL_ALPHA_EN);
+ if (!(pll->flags & SUPPORTS_DYNAMIC_UPDATE) && enabled)
+ hw->init->ops->enable(hw);
+
+ if (pll->flags & SUPPORTS_DYNAMIC_UPDATE)
+ clk_alpha_pll_dynamic_update(pll);
+
return 0;
}
diff --git a/drivers/clk/qcom/clk-alpha-pll.h b/drivers/clk/qcom/clk-alpha-pll.h
index 4bd42fd..23e32db 100644
--- a/drivers/clk/qcom/clk-alpha-pll.h
+++ b/drivers/clk/qcom/clk-alpha-pll.h
@@ -36,6 +36,7 @@ struct clk_alpha_pll {
size_t num_vco;
#define SUPPORTS_VOTE_FSM BIT(0)
+#define SUPPORTS_DYNAMIC_UPDATEBIT(1)
u8 flags;
struct clk_regmap clkr;
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2 07/10] clk: qcom: Add support to enable FSM mode for votable alpha PLLs
The votable alpha PLLs need to have the fsm mode enabled as part
of the initialization. The sequence seems to be the same as used
by clk-pll, so move the function which does this into a common
place and reuse it for the clk-alpha-pll
Signed-off-by: Rajendra Nayak
Signed-off-by: Taniya Das
---
drivers/clk/qcom/clk-alpha-pll.c | 5 +
drivers/clk/qcom/clk-alpha-pll.h | 2 ++
drivers/clk/qcom/clk-pll.c | 25 +++--
drivers/clk/qcom/common.c| 29 +
drivers/clk/qcom/common.h| 2 ++
5 files changed, 41 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 8b8710f..e8f3505 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -18,6 +18,7 @@
#include
#include "clk-alpha-pll.h"
+#include "common.h"
#define PLL_MODE 0x00
# define PLL_OUTCTRL BIT(0)
@@ -133,6 +134,10 @@ void clk_alpha_pll_configure(struct clk_alpha_pll *pll,
struct regmap *regmap,
mask |= config->post_div_mask;
regmap_update_bits(regmap, pll->offset + PLL_USER_CTL, mask, val);
+
+ if (pll->flags & SUPPORTS_VOTE_FSM)
+ qcom_pll_set_fsm_mode(regmap, pll->offset + PLL_MODE, 6, 0);
+
}
static int clk_alpha_pll_hwfsm_enable(struct clk_hw *hw)
diff --git a/drivers/clk/qcom/clk-alpha-pll.h b/drivers/clk/qcom/clk-alpha-pll.h
index 12a349e..4bd42fd 100644
--- a/drivers/clk/qcom/clk-alpha-pll.h
+++ b/drivers/clk/qcom/clk-alpha-pll.h
@@ -35,6 +35,8 @@ struct clk_alpha_pll {
const struct pll_vco *vco_table;
size_t num_vco;
+#define SUPPORTS_VOTE_FSM BIT(0)
+ u8 flags;
struct clk_regmap clkr;
};
diff --git a/drivers/clk/qcom/clk-pll.c b/drivers/clk/qcom/clk-pll.c
index 13d3f64..776278b 100644
--- a/drivers/clk/qcom/clk-pll.c
+++ b/drivers/clk/qcom/clk-pll.c
@@ -23,6 +23,7 @@
#include
#include "clk-pll.h"
+#include "common.h"
#define PLL_OUTCTRLBIT(0)
#define PLL_BYPASSNL BIT(1)
@@ -230,26 +231,6 @@ const struct clk_ops clk_pll_vote_ops = {
EXPORT_SYMBOL_GPL(clk_pll_vote_ops);
static void
-clk_pll_set_fsm_mode(struct clk_pll *pll, struct regmap *regmap, u8 lock_count)
-{
- u32 val;
- u32 mask;
-
- /* De-assert reset to FSM */
- regmap_update_bits(regmap, pll->mode_reg, PLL_VOTE_FSM_RESET, 0);
-
- /* Program bias count and lock count */
- val = 1 << PLL_BIAS_COUNT_SHIFT | lock_count << PLL_LOCK_COUNT_SHIFT;
- mask = PLL_BIAS_COUNT_MASK << PLL_BIAS_COUNT_SHIFT;
- mask |= PLL_LOCK_COUNT_MASK << PLL_LOCK_COUNT_SHIFT;
- regmap_update_bits(regmap, pll->mode_reg, mask, val);
-
- /* Enable PLL FSM voting */
- regmap_update_bits(regmap, pll->mode_reg, PLL_VOTE_FSM_ENA,
- PLL_VOTE_FSM_ENA);
-}
-
-static void
clk_pll_set_dynamic_fsm_mode(struct clk_pll *pll, struct regmap *regmap)
{
u32 val;
@@ -300,7 +281,7 @@ void clk_pll_configure_sr(struct clk_pll *pll, struct
regmap *regmap,
{
clk_pll_configure(pll, regmap, config);
if (fsm_mode)
- clk_pll_set_fsm_mode(pll, regmap, 8);
+ qcom_pll_set_fsm_mode(regmap, pll->mode_reg, 1, 8);
}
EXPORT_SYMBOL_GPL(clk_pll_configure_sr);
@@ -309,7 +290,7 @@ void clk_pll_configure_sr_hpm_lp(struct clk_pll *pll,
struct regmap *regmap,
{
clk_pll_configure(pll, regmap, config);
if (fsm_mode)
- clk_pll_set_fsm_mode(pll, regmap, 0);
+ qcom_pll_set_fsm_mode(regmap, pll->mode_reg, 1, 0);
}
EXPORT_SYMBOL_GPL(clk_pll_configure_sr_hpm_lp);
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index f7c226a..6bf5abd 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -25,6 +25,14 @@
#include "reset.h"
#include "gdsc.h"
+#define PLL_LOCK_COUNT_SHIFT 8
+#define PLL_LOCK_COUNT_MASK0x3f
+#define PLL_BIAS_COUNT_SHIFT 14
+#define PLL_BIAS_COUNT_MASK0x3f
+#define PLL_VOTE_FSM_ENA BIT(20)
+#define PLL_DYN_FSM_ENABIT(20)
+#define PLL_VOTE_FSM_RESET BIT(21)
+
struct qcom_cc {
struct qcom_reset_controller reset;
struct clk_onecell_data data;
@@ -74,6 +82,27 @@ qcom_cc_map(struct platform_device *pdev, const struct
qcom_cc_desc *desc)
}
EXPORT_SYMBOL_GPL(qcom_cc_map);
+void
+qcom_pll_set_fsm_mode(struct regmap *map, u32 reg, u8 bias_count, u8
lock_count)
+{
+ u32 val;
+ u32 mask;
+
+ /* De-assert reset to FSM */
+ regmap_update_bits(map, reg, PLL_VOTE_FSM_RESET, 0);
+
+ /* Program bias count and lock count */
+ val = bias_count << PLL_BIAS_COUNT_SHIFT |
+ lock_count << PLL_LOCK_COUNT_SHIFT;
+ mask = PLL_BIAS_COUNT_MASK << PLL_BIAS_COUNT_SHIFT;
+ mask |= PLL_LOCK_COUNT_MASK << PLL_LOCK_COUNT_SHIFT;
+ regmap_update_bits(map, reg, mask, val);
+
+ /* Enable PLL FSM voting */
+ regmap_u
Re: [PATCH 1/9] kconfig: tinyconfig: provide whole choice blocks to avoid warnings
2016-08-11 6:54 GMT+09:00 Arnd Bergmann : > Using "make tinyconfig" produces a couple of annoying warnings that show up > for build test machines all the time: > > .config:966:warning: override: NOHIGHMEM changes choice state > .config:965:warning: override: SLOB changes choice state > .config:963:warning: override: KERNEL_XZ changes choice state > .config:962:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state > .config:933:warning: override: SLOB changes choice state > .config:930:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state > .config:870:warning: override: SLOB changes choice state > .config:868:warning: override: KERNEL_XZ changes choice state > .config:867:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state > > I've made a previous attempt at fixing them and we discussed a number of > alternatives. > > I tried changing the Makefile to use "merge_config.sh -n $(fragment-list)" > but couldn't get that to work properly. > > This is yet another approach, based on the observation that we do want > to see a warning for conflicting 'choice' options, and that we can simply > make them non-conflicting by listing all other options as disabled. > This is a trivial patch that we can apply independent of plans for other > changes. > > Signed-off-by: Arnd Bergmann > Link: https://storage.kernelci.org/mainline/v4.7-rc6/x86-tinyconfig/build.log > https://patchwork.kernel.org/patch/9212749/ > Reviewed-by: Josh Triplett > Cc: Masahiro Yamada > Cc: Andrew Morton > --- Reviewed-by: Masahiro Yamada -- Best Regards Masahiro Yamada
[PATCH v2 01/10] clk: Fix inconsistencies in usage of data types
index is of type u8 in all places except in clk_hw_get_parent_by_index()
and return value of all round_rate functions is long except for
clk_hw_round_rate(). Make them consistent with the rest of the places
Signed-off-by: Rajendra Nayak
---
drivers/clk/clk.c| 4 ++--
include/linux/clk-provider.h | 5 ++---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..e768071 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -261,7 +261,7 @@ static struct clk_core *clk_core_get_parent_by_index(struct
clk_core *core,
}
struct clk_hw *
-clk_hw_get_parent_by_index(const struct clk_hw *hw, unsigned int index)
+clk_hw_get_parent_by_index(const struct clk_hw *hw, u8 index)
{
struct clk_core *parent;
@@ -889,7 +889,7 @@ int __clk_determine_rate(struct clk_hw *hw, struct
clk_rate_request *req)
}
EXPORT_SYMBOL_GPL(__clk_determine_rate);
-unsigned long clk_hw_round_rate(struct clk_hw *hw, unsigned long rate)
+long clk_hw_round_rate(struct clk_hw *hw, unsigned long rate)
{
int ret;
struct clk_rate_request req;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index a39c0c5..230a249 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -732,8 +732,7 @@ const char *clk_hw_get_name(const struct clk_hw *hw);
struct clk_hw *__clk_get_hw(struct clk *clk);
unsigned int clk_hw_get_num_parents(const struct clk_hw *hw);
struct clk_hw *clk_hw_get_parent(const struct clk_hw *hw);
-struct clk_hw *clk_hw_get_parent_by_index(const struct clk_hw *hw,
- unsigned int index);
+struct clk_hw *clk_hw_get_parent_by_index(const struct clk_hw *hw, u8 index);
unsigned int __clk_get_enable_count(struct clk *clk);
unsigned long clk_hw_get_rate(const struct clk_hw *hw);
unsigned long __clk_get_flags(struct clk *clk);
@@ -760,7 +759,7 @@ static inline void __clk_hw_set_clk(struct clk_hw *dst,
struct clk_hw *src)
/*
* FIXME clock api without lock protection
*/
-unsigned long clk_hw_round_rate(struct clk_hw *hw, unsigned long rate);
+long clk_hw_round_rate(struct clk_hw *hw, unsigned long rate);
struct of_device_id;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] usb: core: Add runtime resume checking
On 11 August 2016 at 16:19, Peter Chen wrote: > On Thu, Aug 11, 2016 at 04:07:21PM +0800, Baolin Wang wrote: >> Hi Peter, >> >> On 11 August 2016 at 14:54, Peter Chen wrote: >> > On Thu, Aug 11, 2016 at 11:08:52AM +0800, Baolin Wang wrote: >> >> Hi Alan, >> >> >> >> On 10 August 2016 at 22:25, Alan Stern wrote: >> >> > On Wed, 10 Aug 2016, Baolin Wang wrote: >> >> > >> >> >> >> >> For example: No slave attached> usb interface runtime suspend >> >> >> >> >> > usb device runtime suspend -> xhci suspend -> >> >> >> >> >> power off >> >> >> >> >> usb controller. After that if the system wants to enter suspend >> >> >> >> >> state, >> >> >> >> >> then it also will issue usb_dev_suspend(), then the >> >> >> >> >> pm_runtime_resume() function (issued in choose_wakeup() >> >> >> >> >> function) will >> >> >> >> >> return -ESHUTDOWN due to xhci has been suspend and hardware is >> >> >> >> >> not >> >> >> >> >> accessible. >> >> >> >> > >> >> >> >> > Why the controller does not be resumed when the root hub has >> >> >> >> > issued >> >> >> >> > runtime resume? >> >> >> >> >> >> >> >> Because now there is no slave attached, we will not power on usb >> >> >> >> controller and resume xhci. >> >> >> >> >> >> >> > >> >> >> > I don't know why you set policy like this. Even the controller is >> >> >> > resumed, it will still be suspended by system suspend. What's more, >> >> >> > if you disallow it, how can you change your wakeup setting? >> >> >> > Eg, at runtime suspend, we enable wakeup by default. But for system >> >> >> > sleep, we disable wakeup by default. >> >> >> > >> >> >> > At runtime, if there is no device on the port, even we resumes the >> >> >> > controller and roohub, it still will be suspended soon. >> >> >> >> >> >> For saving power, if there is no slave attached, why we need to power >> >> >> on usb controller and resume xhci? Especially for mobile device. >> >> > >> >> > You need to power-on the USB controller in order to change the wakeup >> >> > setting. >> >> >> >> pm_runtime_resume() function issued in choose_wakeup() can just resume >> >> usb device, which can not power-on the USB controller and resume xHCI. >> >> Cause the user won't know you need to power-on usb controller now, >> >> then how to power-on the USB controller when changing wakeup setting? >> >> >> >> > >> >> >> Moreover the usb device runtime suspend/resume is separate with xhci >> >> >> suspend/resume, when xhci entered suspend state, only slave attaching >> >> >> can resume xhci. >> >> > >> >> > That's right. Suppose the user wants the system to stay asleep when a >> >> > slave attaches. But when you suspended the xHCI controller, it was set >> >> > to wake up when a new slave attaches. So when a slave is attached, the >> >> > controller will wake up the system. That's bad. >> >> > >> >> > If the wakeup setting needs to be changed when the system suspend >> >> > begins, then you have to power-on the controller to make that change. >> >> > >> >> > Given a choice between using a little power or behaving incorrectly, >> >> > you should choose to use the power. >> >> >> >> OK. But that is a real problem. It will pm_runtime_resume() falied >> >> (issued in choose_wakeup()), cause usb controller has powered-off and >> >> xHCI controller has suspended and we have no method to notify the user >> >> to power-on USB controller. Any good suggestion to solve this, Alan >> >> and Peter? Thanks. >> >> >> > >> > Maybe you can show us the call stack why pm_runtime_resume has failed >> > at your environment. >> >> OK. I try to explain it at below: >> >> For example: No slave attached> usb interface runtime suspend >> > usb device runtime suspend (routine is: >> usb_suspend_device()--->generic_suspend() --> hcd_bus_suspend()--> >> xhci_bus_suspend()) -> xhci_ suspend() -> power off usb >> controller. After that if the system wants to enter suspend state, >> then it also will issue usb_dev_suspend(), then the >> pm_runtime_resume() function (issued in choose_wakeup() function) will >> return -ESHUTDOWN due to xhci has been suspend and hardware is not >> accessible. >> >> We issue the pm_runtime_resume() function routine: usb_resume_device() >> > generic_resume() > hcd_bus_resume() ---> xhci_bus_resume(), >> but now xHCI is not accessible due to xhci_suspend() is issued and USB >> controller is power off when no slave attached. That is why >> pm_runtime_resume failed. >> > > What host controller driver you are using? Assume you are using > xhci-plat.c. The problem for you is this driver does not implement Yes. I use xhci-plat.c. > runtime pm operations, so the flag HCD_FLAG_HW_ACCESSIBLE is not set. > Maybe Robert's patch is a good start for you [1] > > [1] http://www.spinics.net/lists/linux-usb/msg144602.html OK. Maybe I need to implement the runtime PM callbacks for xhci-plat, right? -- Baolin.wang Best Regards
[PATCH v2 00/10] clk: qcom: PLL updates
Hi, This series adds some additional support to the clk-alpha-pll and the clk-pll drivers in preperation to add the CPU clock driver support on msm8996 Changes in v2: * Patch 1 to 6 are same as v1 post, added patches 7 to 10 Rajendra Nayak (8): clk: Fix inconsistencies in usage of data types clk: qcom: Add support for alpha pll hwfsm ops clk: qcom: Add support to initialize alpha plls clk: qcom: Add support for PLLs with alpha mode clk: qcom: Add support for PLLs with early output clk: qcom: Add support for PLLs supporting dynamic reprogramming clk: qcom: Add support to enable FSM mode for votable alpha PLLs clk: qcom: Add .is_enabled ops for clk-alpha-pll Taniya Das (2): clk: qcom: Cleanup some macro defs clk: qcom: Fix .set_rate to handle alpha PLLs w/wo dynamic update drivers/clk/clk.c| 4 +- drivers/clk/qcom/clk-alpha-pll.c | 235 ++- drivers/clk/qcom/clk-alpha-pll.h | 17 +++ drivers/clk/qcom/clk-pll.c | 123 +--- drivers/clk/qcom/clk-pll.h | 12 +- drivers/clk/qcom/common.c| 29 + drivers/clk/qcom/common.h| 2 + include/linux/clk-provider.h | 5 +- 8 files changed, 378 insertions(+), 49 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [RFC PATCH v3 13/13] drivers: acpi: iort: introduce iort_iommu_configure
On Wed, Aug 03, 2016 at 10:19:43AM -0400, nwatt...@codeaurora.org wrote:
[...]
> >+const struct iommu_ops *iort_iommu_configure(struct device *dev)
> >+{
> >+struct acpi_iort_node *node, *parent;
> >+struct fwnode_handle *iort_fwnode;
> >+u32 rid = 0, devid = 0;
>
> Since this routine maps the RID space of a device to the StreamID
> space of its
> parent smmu, would you consider renaming the devid variable to some
> form of sid
> or streamid?
>
> >+
> >+if (dev_is_pci(dev)) {
> >+struct pci_bus *bus = to_pci_dev(dev)->bus;
> >+
> >+pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid,
> >+ &rid);
> >+
> >+node = iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
> >+ iort_match_node_callback, &bus->dev);
> >+} else {
> >+node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
> >+ iort_match_node_callback, dev);
> >+}
> >+
> >+if (!node)
> >+return NULL;
> >+
> >+parent = iort_node_map_rid(node, rid, &devid, IORT_IOMMU_TYPE);
> >+if (parent) {
> >+iort_fwnode = iort_get_fwnode(parent);
> >+if (iort_fwnode) {
> >+arm_smmu_iort_xlate(dev, devid, iort_fwnode);
>
> What about named components with multiple stream ids? Since
> establishing the relationship between a named component and its parent
> smmu is already dependent on there being an appropriate mapping of rid
> 0, it stands to reason that all of the stream ids for a named
> component could be enumerated by mapping increasing rid values until
> the output parent no longer matches that returned for rid 0.
I have reworked the code since for named component it makes no
sense to carry out a mapping that depends on an input id given
that we do not have one. Instead what we will do is the same
thing DT does (ie "iommus" property), namely walk the array of
single mappings for a given named component (that do not depend
on the input rid, there is not any) and add them to the translation
as we find them.
Ergo, mappings that are not single mappings are pretty much useless
for named components (for the time being), and I won't allow them.
Thoughts ?
Lorenzo
>
> >+return fwspec_iommu_get_ops(iort_fwnode);
> >+}
> >+}
> >+
> >+return NULL;
> >+}
>
> It should be noted that while trying out the approach described
> above, I noticed
> that each of the smmu attached named components described in my iort
> were ending
> up with an extra stream id. The culprit appears to be that the range
> checking in
> iort_id_map() is overly permissive on the upper bounds. For example,
> mappings
> with input_base=N and id_count=1 were matching both N and N+1. The
> following
> change fixed the issue.
>
> @@ -296,7 +296,7 @@ iort_id_map(struct acpi_iort_id_mapping *map, u8
> type, u32 rid_in, u32 *rid_out)
> }
>
> if (rid_in < map->input_base ||
> - (rid_in > map->input_base + map->id_count))
> + (rid_in >= map->input_base + map->id_count))
> return -ENXIO;
>
> *rid_out = map->output_base + (rid_in - map->input_base);
>
> >+
> > static void acpi_smmu_v3_register_irq(int hwirq, const char *name,
> > struct resource *res)
> > {
> >diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> >index b4b9064..de28825 100644
> >--- a/drivers/acpi/scan.c
> >+++ b/drivers/acpi/scan.c
> >@@ -7,6 +7,7 @@
> > #include
> > #include
> > #include
> >+#include
> > #include
> > #include
> > #include
> >@@ -1365,11 +1366,15 @@ enum dev_dma_attr acpi_get_dma_attr(struct
> >acpi_device *adev)
> > */
> > void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> > {
> >+const struct iommu_ops *iommu;
> >+
> >+iommu = iort_iommu_configure(dev);
> >+
> > /*
> > * Assume dma valid range starts at 0 and covers the whole
> > * coherent_dma_mask.
> > */
> >-arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, NULL,
> >+arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, iommu,
> >attr == DEV_DMA_COHERENT);
>
> If dev has a matching named component iort entry with a non-zero
> value for
> memory_address_limit, why not use that as the size input to
> arch_setup_dma_ops?
>
> > }
> >
> >diff --git a/include/linux/iort.h b/include/linux/iort.h
> >index 18e6836..bbe08ef 100644
> >--- a/include/linux/iort.h
> >+++ b/include/linux/iort.h
> >@@ -34,6 +34,8 @@ struct irq_domain *iort_get_device_domain(struct
> >device *dev, u32 req_id);
> > /* IOMMU interface */
> > int iort_add_smmu_platform_device(struct fwnode_handle *fwnode,
> > struct acpi_iort_node *node);
> >+
> >+const struct iommu_ops *iort_iommu_configure(struct device *dev);
> > #else
> > static inline bool iort_node_match(u8 type) { return false; }
> > static inline void
Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver
On 08/11/2016 09:14 AM, Andreas Werner wrote: On Wed, Aug 10, 2016 at 10:28:45PM +0200, Oliver Hartkopp wrote: Just check 'git grep IFF_ECHO'. Even grcan.c and janz-ican3.c have IFF_ECHO set - but implement it in a different way without using the provided machanism from dev.c . Ok I am with you. Great :-) A local loopback inside the CAN controller which is generated after successful transmit is an excellent implementation with excellent timestamps. The only problem for you is to detect the looped CAN frames and match them to the skb pointer of the outgoing frame to 'receive' the correct echo skb. At the moment, i think there is no way to detect those looped frames. I will talk to our IC designer and discuss this issue with him. Maybe we have the possibility to get a local loopback inside the CAN controller. This seems to be the best way to do it. When you still have the possibility to change the IP core I would suggest to create some kind of 16/32 bit value which you can pass to the CAN controller along with the CAN frame to be sent. And when this frame comes back due to the loopback you can use this non-zero 16/32 bit value to match into a list of tx skb pointers for IFF_ECHO. E.g. when this 16/32 bit value is zero this CAN frame obviously was received from another CAN node. Just an idea. Regards, Oliver
Re: [PATCH v5 2/2] Add support for SCT Write Same
On 11 August 2016 at 09:47, Martin K. Petersen wrote: > > Tom> so we can at most allow only a 2-block (well, or 3-block) payload. > > We tried turning on multi block payloads and it was a massive disaster. > Many drives reported that they supported 8 block payloads but actually > didn't. Instead of playing the blacklist game we capped it at a single > sector. I don't know, apparently Windows does multi block payloads though (at least that's how it advertise on the simulated VPD). What I meant was it will not make a big difference in our case anyway. Given the 32-bit representation limitation, we could be at best using a full 2-block payload. So let's not do 2 but 1? Fine :P > > Many drives from different vendors were affected by this. So we'd have > to make multi block payloads an explicit opt-in like we did for > discard_zeroes_data. However, given that "big" discards are mainly done > synchronously when creating filesystems, I am not sure there is any real > benefit to this. > Probably. Perhaps it could make a difference upon deletion of some really big files (though the logical sectors used may not be continuous anyway). > -- > Martin K. Petersen Oracle Linux Engineering
[PATCH v2 03/10] clk: qcom: Add support to initialize alpha plls
Add a function to do initial configuration of the alpha plls
Signed-off-by: Rajendra Nayak
---
drivers/clk/qcom/clk-alpha-pll.c | 23 +++
drivers/clk/qcom/clk-alpha-pll.h | 13 +
2 files changed, 36 insertions(+)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index bae31f9..8b8710f 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -112,6 +112,29 @@ static int wait_for_pll_offline(struct clk_alpha_pll *pll,
u32 mask)
#define PLL_OFFLINE_ACKBIT(28)
#define PLL_ACTIVE_FLAGBIT(30)
+void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
+const struct alpha_pll_config *config)
+{
+ u32 val, mask;
+
+ regmap_write(regmap, pll->offset + PLL_CONFIG_CTL,
+config->config_ctl_val);
+
+ val = config->main_output_mask;
+ val |= config->aux_output_mask;
+ val |= config->aux2_output_mask;
+ val |= config->early_output_mask;
+ val |= config->post_div_val;
+
+ mask = config->main_output_mask;
+ mask |= config->aux_output_mask;
+ mask |= config->aux2_output_mask;
+ mask |= config->early_output_mask;
+ mask |= config->post_div_mask;
+
+ regmap_update_bits(regmap, pll->offset + PLL_USER_CTL, mask, val);
+}
+
static int clk_alpha_pll_hwfsm_enable(struct clk_hw *hw)
{
int ret;
diff --git a/drivers/clk/qcom/clk-alpha-pll.h b/drivers/clk/qcom/clk-alpha-pll.h
index f78bf4c..12a349e 100644
--- a/drivers/clk/qcom/clk-alpha-pll.h
+++ b/drivers/clk/qcom/clk-alpha-pll.h
@@ -51,8 +51,21 @@ struct clk_alpha_pll_postdiv {
struct clk_regmap clkr;
};
+struct alpha_pll_config {
+ u32 config_ctl_val;
+ u32 main_output_mask;
+ u32 aux_output_mask;
+ u32 aux2_output_mask;
+ u32 early_output_mask;
+ u32 post_div_val;
+ u32 post_div_mask;
+};
+
extern const struct clk_ops clk_alpha_pll_ops;
extern const struct clk_ops clk_alpha_pll_hwfsm_ops;
extern const struct clk_ops clk_alpha_pll_postdiv_ops;
+void clk_alpha_pll_configure(struct clk_alpha_pll *pll, struct regmap *regmap,
+const struct alpha_pll_config *config);
+
#endif
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2 04/10] clk: qcom: Add support for PLLs with alpha mode
Some PLLs can support an alpha mode, and a single alpha
register (instead of registers to program the M/N values),
the contents of which depend on the alpha mode selected.
(They are either treated as two's complement or M/N value)
Add support for this in the clk PLL driver.
Signed-off-by: Rajendra Nayak
---
drivers/clk/qcom/clk-pll.c | 8 ++--
drivers/clk/qcom/clk-pll.h | 2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/qcom/clk-pll.c b/drivers/clk/qcom/clk-pll.c
index 5b940d6..08d2fa2 100644
--- a/drivers/clk/qcom/clk-pll.c
+++ b/drivers/clk/qcom/clk-pll.c
@@ -255,8 +255,12 @@ static void clk_pll_configure(struct clk_pll *pll, struct
regmap *regmap,
u32 mask;
regmap_write(regmap, pll->l_reg, config->l);
- regmap_write(regmap, pll->m_reg, config->m);
- regmap_write(regmap, pll->n_reg, config->n);
+ if (pll->alpha_reg) {
+ regmap_write(regmap, pll->alpha_reg, config->alpha);
+ } else {
+ regmap_write(regmap, pll->m_reg, config->m);
+ regmap_write(regmap, pll->n_reg, config->n);
+ }
val = config->vco_val;
val |= config->pre_div_val;
diff --git a/drivers/clk/qcom/clk-pll.h b/drivers/clk/qcom/clk-pll.h
index ffd0c63..083727e 100644
--- a/drivers/clk/qcom/clk-pll.h
+++ b/drivers/clk/qcom/clk-pll.h
@@ -48,6 +48,7 @@ struct clk_pll {
u32 l_reg;
u32 m_reg;
u32 n_reg;
+ u32 alpha_reg;
u32 config_reg;
u32 mode_reg;
u32 status_reg;
@@ -70,6 +71,7 @@ struct pll_config {
u16 l;
u32 m;
u32 n;
+ u32 alpha;
u32 vco_val;
u32 vco_mask;
u32 pre_div_val;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2 02/10] clk: qcom: Add support for alpha pll hwfsm ops
Add support to enable/disable the alpha pll using hwfsm
Signed-off-by: Rajendra Nayak
---
drivers/clk/qcom/clk-alpha-pll.c | 109 ++-
drivers/clk/qcom/clk-alpha-pll.h | 1 +
2 files changed, 98 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index e6a03ea..bae31f9 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -62,9 +62,10 @@
#define to_clk_alpha_pll_postdiv(_hw) container_of(to_clk_regmap(_hw), \
struct clk_alpha_pll_postdiv, clkr)
-static int wait_for_pll(struct clk_alpha_pll *pll)
+static int wait_for_pll(struct clk_alpha_pll *pll, u32 mask, bool inverse,
+ const char *action)
{
- u32 val, mask, off;
+ u32 val, off;
int count;
int ret;
const char *name = clk_hw_get_name(&pll->clkr.hw);
@@ -74,26 +75,101 @@ static int wait_for_pll(struct clk_alpha_pll *pll)
if (ret)
return ret;
- if (val & PLL_VOTE_FSM_ENA)
- mask = PLL_ACTIVE_FLAG;
- else
- mask = PLL_LOCK_DET;
-
- /* Wait for pll to enable. */
for (count = 100; count > 0; count--) {
ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, &val);
if (ret)
return ret;
- if ((val & mask) == mask)
+ if (inverse && (val & mask))
+ return 0;
+ else if ((val & mask) == mask)
return 0;
udelay(1);
}
- WARN(1, "%s didn't enable after voting for it!\n", name);
+ WARN(1, "%s failed to %s!\n", name, action);
return -ETIMEDOUT;
}
+static int wait_for_pll_enable(struct clk_alpha_pll *pll, u32 mask)
+{
+ return wait_for_pll(pll, mask, 0, "enable");
+}
+
+static int wait_for_pll_disable(struct clk_alpha_pll *pll, u32 mask)
+{
+ return wait_for_pll(pll, mask, 1, "disable");
+}
+
+static int wait_for_pll_offline(struct clk_alpha_pll *pll, u32 mask)
+{
+ return wait_for_pll(pll, mask, 0, "offline");
+}
+
+/* alpha pll with hwfsm support */
+#define PLL_OFFLINE_REQBIT(7)
+#define PLL_FSM_ENABIT(20)
+#define PLL_OFFLINE_ACKBIT(28)
+#define PLL_ACTIVE_FLAGBIT(30)
+
+static int clk_alpha_pll_hwfsm_enable(struct clk_hw *hw)
+{
+ int ret;
+ u32 val, off;
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+
+ off = pll->offset;
+ ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, &val);
+ if (ret)
+ return ret;
+
+ /* Enable HW FSM mode, clear OFFLINE request */
+ val |= PLL_FSM_ENA;
+ val &= ~PLL_OFFLINE_REQ;
+ ret = regmap_write(pll->clkr.regmap, off + PLL_MODE, val);
+ if (ret)
+ return ret;
+
+ /* Make sure enable request goes through before waiting for update */
+ mb();
+
+ ret = wait_for_pll_enable(pll, PLL_ACTIVE_FLAG);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static void clk_alpha_pll_hwfsm_disable(struct clk_hw *hw)
+{
+ int ret;
+ u32 val, off;
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+
+ off = pll->offset;
+ ret = regmap_read(pll->clkr.regmap, off + PLL_MODE, &val);
+ if (ret)
+ return;
+
+ /* Request PLL_OFFLINE and wait for ack */
+ ret = regmap_update_bits(pll->clkr.regmap, off + PLL_MODE,
+PLL_OFFLINE_REQ, PLL_OFFLINE_REQ);
+ if (ret)
+ return;
+
+ ret = wait_for_pll_offline(pll, PLL_OFFLINE_ACK);
+ if (ret)
+ return;
+
+ /* Disable hwfsm */
+ ret = regmap_update_bits(pll->clkr.regmap, off + PLL_MODE,
+PLL_FSM_ENA, 0);
+ if (ret)
+ return;
+
+ wait_for_pll_disable(pll, PLL_ACTIVE_FLAG);
+}
+
static int clk_alpha_pll_enable(struct clk_hw *hw)
{
int ret;
@@ -112,7 +188,7 @@ static int clk_alpha_pll_enable(struct clk_hw *hw)
ret = clk_enable_regmap(hw);
if (ret)
return ret;
- return wait_for_pll(pll);
+ return wait_for_pll_enable(pll, PLL_ACTIVE_FLAG);
}
/* Skip if already enabled */
@@ -136,7 +212,7 @@ static int clk_alpha_pll_enable(struct clk_hw *hw)
if (ret)
return ret;
- ret = wait_for_pll(pll);
+ ret = wait_for_pll_enable(pll, PLL_LOCK_DET);
if (ret)
return ret;
@@ -300,6 +376,15 @@ const struct clk_ops clk_alpha_pll_ops = {
};
EXPORT_SYMBOL_GPL(clk_alpha_pll_ops);
+const struct clk_ops clk_alpha_pll_hwfsm_ops = {
+ .enable = clk_alpha_pll_hwfsm_enable,
+ .disable = clk_alpha_pll_hwfsm_disable,
+ .recalc_rate = clk_alpha
Re: [PATCH 2/2] x86, ACPI: Fix the wrong assignment when Handle apic/x2apic entries
* Baoquan He wrote:
> On 08/10/16 at 02:53pm, Ingo Molnar wrote:
> >
> > * Baoquan He wrote:
> >
> > > It won't impact the result, we still should fix the code bug.
> > >
> > > Signed-off-by: Baoquan He
> > > Cc: "Rafael J. Wysocki"
> > > Cc: Len Brown
> > > Cc: Pavel Machek
> > > Cc: Thomas Gleixner
> > > Cc: Ingo Molnar
> > > Cc: "H. Peter Anvin"
> > > Cc: x...@kernel.org
> > > Cc: linux...@vger.kernel.org
> > > ---
> > > arch/x86/kernel/acpi/boot.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> > > index 90d84c3..2b25d3f 100644
> > > --- a/arch/x86/kernel/acpi/boot.c
> > > +++ b/arch/x86/kernel/acpi/boot.c
> > > @@ -1031,8 +1031,8 @@ static int __init
> > > acpi_parse_madt_lapic_entries(void)
> > > return ret;
> > > }
> > >
> > > - x2count = madt_proc[0].count;
> > > - count = madt_proc[1].count;
> > > + count = madt_proc[0].count;
> > > + x2count = madt_proc[1].count;
> > > }
> > > if (!count && !x2count) {
> ~
> I mean here the value checking won't be impacted by the wrong
> assignment.
Indeed!
Mind putting that into the changelog? Something like:
"By pure accident the bug makes no functional difference, because the only
expression where we are using these values is (!count && !x2count), in which
the variables are interchangeable, but it makes sense to fix the bug
nevertheless."
Thanks,
Ingo
[REGRESSION] Secure discard is broken
Hi
I noticed some changes in the mmc block driver that did not go
through the mmc tree and they looked wrong so I gave them a test.
And it does seem like secure discard is broken, not just for mmc
but in general too. The commit was:
288dab8a35a0 ("block: add a separate operation type for secure erase")
When I tried it, it gets stuck in blk_queue_bio:
# Performing secure-erase from 512000 count 4096 (from sector 1000
sector count 8)
[ 942.771946] INFO: rcu_sched self-detected stall on CPU
[ 942.777800] 2-...: (20998 ticks this GP) idle=3ed/141/0
softirq=2568/2568 fqs=5250
[ 942.787765] (t=21000 jiffies g=1729 c=1728 q=202)
[ 942.793307] Task dump for CPU 2:
[ 942.796956] mmc-erase4.stat R running task14512 1936 1605 0x0008
[ 942.804984] 0087 880173c83dd8 81080eef
0002
[ 942.813414] 0087 880173c83df0 810833e4
0002
[ 942.821850] 880173c83e20 81123635 880173c988c0
81e431c0
[ 942.830292] Call Trace:
[ 942.833056][] sched_show_task+0xbf/0x120
[ 942.840179] [] dump_cpu_task+0x34/0x40
[ 942.846307] [] rcu_dump_cpu_stacks+0x79/0xb4
[ 942.853023] [] rcu_check_callbacks+0x717/0x870
[ 942.859937] [] ? __acct_update_integrals+0x2c/0xb0
[ 942.867244] [] ? tick_sched_do_timer+0x30/0x30
[ 942.874158] [] update_process_times+0x2a/0x50
[ 942.880971] [] tick_sched_handle.isra.13+0x31/0x40
[ 942.888273] [] tick_sched_timer+0x38/0x70
[ 942.894688] [] __hrtimer_run_queues+0xda/0x250
[ 942.901602] [] hrtimer_interrupt+0xa3/0x190
[ 942.908219] [] local_apic_timer_interrupt+0x33/0x60
[ 942.915627] [] smp_apic_timer_interrupt+0x38/0x50
[ 942.922837] [] apic_timer_interrupt+0x7f/0x90
[ 942.929651][] ? blk_queue_split+0x251/0x520
[ 942.937074] [] ? create_task_io_context+0x1c/0xf0
[ 942.944282] [] blk_queue_bio+0x40/0x350
[ 942.950506] [] generic_make_request+0xcb/0x1a0
[ 942.957403] [] submit_bio+0x66/0x120
[ 942.963328] [] ? next_bio+0x18/0x40
[ 942.969159] [] ? __blkdev_issue_discard+0x153/0x1b0
[ 942.976564] [] submit_bio_wait+0x49/0x60
[ 942.982886] [] blkdev_issue_discard+0x65/0xa0
[ 942.989701] [] ? __wake_up+0x3f/0x50
[ 942.995632] [] ? tty_ldisc_deref+0x11/0x20
[ 943.002151] [] blk_ioctl_discard+0x78/0x90
[ 943.008658] [] blkdev_ioctl+0x714/0x8a0
[ 943.014880] [] block_ioctl+0x38/0x40
[ 943.020801] [] do_vfs_ioctl+0x8b/0x590
[ 943.026925] [] SyS_ioctl+0x74/0x80
[ 943.032656] [] entry_SYSCALL_64_fastpath+0x13/0x8f
I made a few hacks that seemed to make it go but I expect there are more
places to change:
diff --git a/block/bio.c b/block/bio.c
index f39477538fef..8a69af062b9c 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -667,7 +667,7 @@ struct bio *bio_clone_bioset(struct bio *bio_src, gfp_t
gfp_mask,
bio->bi_iter.bi_sector = bio_src->bi_iter.bi_sector;
bio->bi_iter.bi_size= bio_src->bi_iter.bi_size;
- if (bio_op(bio) == REQ_OP_DISCARD)
+ if (bio_op(bio) == REQ_OP_DISCARD || bio_op(bio) == REQ_OP_SECURE_ERASE)
goto integrity_clone;
if (bio_op(bio) == REQ_OP_WRITE_SAME) {
@@ -1788,7 +1788,7 @@ struct bio *bio_split(struct bio *bio, int sectors,
* Discards need a mutable bio_vec to accommodate the payload
* required by the DSM TRIM and UNMAP commands.
*/
- if (bio_op(bio) == REQ_OP_DISCARD)
+ if (bio_op(bio) == REQ_OP_DISCARD || bio_op(bio) == REQ_OP_SECURE_ERASE)
split = bio_clone_bioset(bio, gfp, bs);
else
split = bio_clone_fast(bio, gfp, bs);
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 3eec75a9e91d..b995ab078755 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -172,7 +172,8 @@ void blk_queue_split(struct request_queue *q, struct bio
**bio,
struct bio *split, *res;
unsigned nsegs;
- if (bio_op(*bio) == REQ_OP_DISCARD)
+ if (bio_op(*bio) == REQ_OP_DISCARD ||
+ bio_op(*bio) == REQ_OP_SECURE_ERASE)
split = blk_bio_discard_split(q, *bio, bs, &nsegs);
else if (bio_op(*bio) == REQ_OP_WRITE_SAME)
split = blk_bio_write_same_split(q, *bio, bs, &nsegs);
@@ -213,7 +214,7 @@ static unsigned int __blk_recalc_rq_segments(struct
request_queue *q,
* This should probably be returning 0, but blk_add_request_payload()
* (Christoph)
*/
- if (bio_op(bio) == REQ_OP_DISCARD)
+ if (bio_op(bio) == REQ_OP_DISCARD || bio_op(bio) == REQ_OP_SECURE_ERASE)
return 1;
if (bio_op(bio) == REQ_OP_WRITE_SAME)
@@ -385,7 +386,8 @@ static int __blk_bios_map_sg(struct request_queue *q,
struct bio *bio,
nsegs = 0;
cluster = blk_queue_cluster(q);
- if (bio_op(bio) == REQ_OP_DISCARD) {
+ if (bio_op(bio) == REQ_OP_DISCARD ||
+ bio_op(bio) == REQ_OP_SECURE_ERASE) {
/*
* Thi
Re: A bug in ftrace - dynamic fops
On Tue, 9 Aug 2016, Steven Rostedt wrote: > On Tue, 9 Aug 2016 10:16:00 +0200 (CEST) > Miroslav Benes wrote: > > > > I agree it is kind of shooting oneself in the foot bug, because explicit > > call to a sleeping function may not be the brightest thing to do. However > > I see two (closely related) issues with this. > > > > 1. It is a change in behaviour. Ftrace silently relies on an atomicity of > > ops->func(). I don't see it documented anywhere, but it did not matter > > because the atomicity was always guaranteed as described above. Now there > > is a possibility to achieve a situation which breaks the assumption. It > > makes me worried. > > Why? It's something that a kernel developer should be aware of. I mean, > that ops->func can easily be called from *any* context, like irq, > softirq, or even an NMI. One who hooks into any function of the kernel > should understand that it has special requirements, just like we don't > document that you can't sleep in an NMI. > > And if you only hook to functions that can sleep, then great! You are > allowed to do that too. Just like calling a module function that can > sleep. You need to make sure nothing is calling your function when you > unload the module. I don't see anything that is deceptive here. At least the comment in ftrace_shutdown() is deceptive. But well, I understood your opinion from the first reply. I just didn't agree with it and that's why I expressed it. > > > > 2. Previously if someone called a function which could sleep he was > > immediately warned not to do so via "sleeping in atomic context" BUG. Now > > he wouldn't know. That's because in_atomic() and might_sleep() > > infrastructure does not work in ops->func(). in_atomic() gives 0 even if > > it is an atomic context in fact. But well, the comment for in_atomic() in > > linux/preempt.h warns about exactly this situation I guess. > > It will warn if you hook to a function that can sleep. And if you never > do, then there's nothing wrong. If the only functions you hook to can > sleep, then it is fine for you to sleep in your code too. But if you > do, you must synchronize that logic. You must make sure all functions > are out of the sleep when you unresgister. Just like you must make sure > all functions are out of a sleeping function in a module. This is > kernel programming 101. > > I never saw a need to have sleeping functions being called by > ops->func() and I don't know of a case that would. If there is a > legitimate case (not hypothetical) and then I could add a way to > postpone freeing of an ops if need be. > > Because note, that TASK_RCU will only be called when CONFIG_PREEMPT is > enabled. It would be overkill to do it for !CONFIG_PREEMPT, thus it > will not solve what you want here. Fair enough. I can live with that. Miroslav
[PATCH] perf tools mem: Fix -t store option for record command
Michael reported 'perf mem -t store record' being broken.
The reason is latest rework of this area:
commit acbe613e0c03 ("perf tools: Add monitored events array")
We don't mark perf_mem_events store record when -t store
option is specified.
Fixes: commit acbe613e0c03 ("perf tools: Add monitored events array")
Reported-by: Michael Petlan
Link: http://lkml.kernel.org/n/tip-dbytnk7urdnnaw7ckdu1w...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-mem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index d608a2c9e48c..d1ce29be560e 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -88,6 +88,9 @@ static int __cmd_record(int argc, const char **argv, struct
perf_mem *mem)
if (mem->operation & MEM_OPERATION_LOAD)
perf_mem_events[PERF_MEM_EVENTS__LOAD].record = true;
+ if (mem->operation & MEM_OPERATION_STORE)
+ perf_mem_events[PERF_MEM_EVENTS__STORE].record = true;
+
if (perf_mem_events[PERF_MEM_EVENTS__LOAD].record)
rec_argv[i++] = "-W";
--
2.4.11
[PATCH] powerpc: sysdev: cpm: fix gpio save_regs functions
of_mm_gpiochip_add_data() calls mm_gc->save_regs() before
setting the data. Therefore ->save_regs() cannot use
gpiochip_get_data()
[0.275940] Unable to handle kernel paging request for data at address
0x0130
[0.283120] Faulting instruction address: 0xc01b44cc
[0.288175] Oops: Kernel access of bad area, sig: 11 [#1]
[0.293343] PREEMPT CMPC885
[0.296141] CPU: 0 PID: 1 Comm: swapper Not tainted 4.7.0-g65124df-dirty #68
[0.304131] task: c6074000 ti: c608 task.ti: c608
[0.309459] NIP: c01b44cc LR: c0011720 CTR: c0011708
[0.314372] REGS: c6081d90 TRAP: 0300 Not tainted (4.7.0-g65124df-dirty)
[0.322267] MSR: 9032 CR: 2428 XER: 2000
[0.328813] DAR: 0130 DSISR: c000
GPR00: c01b6d0c c6081e40 c6074000 c6017000 c9028000 c601d028 c6081dd8
GPR08: c601d028 0001 2444 c0002790
GPR16: c05643b0 0083
GPR24: c04a1a6c c056 c04a8308 c04c6480 c0012498 c6017000 c7ffcc78 c6017000
[0.360806] NIP [c01b44cc] gpiochip_get_data+0x4/0xc
[0.365684] LR [c0011720] cpm1_gpio16_save_regs+0x18/0x44
[0.370972] Call Trace:
[0.373451] [c6081e50] [c01b6d0c] of_mm_gpiochip_add_data+0x70/0xdc
[0.379624] [c6081e70] [c00124c0] cpm_init_par_io+0x28/0x118
[0.385238] [c6081e80] [c04a8ac0] do_one_initcall+0xb0/0x17c
[0.390819] [c6081ef0] [c04a8cbc] kernel_init_freeable+0x130/0x1dc
[0.396924] [c6081f30] [c00027a4] kernel_init+0x14/0x110
[0.402177] [c6081f40] [c000b424] ret_from_kernel_thread+0x5c/0x64
[0.408233] Instruction dump:
[0.411168] 4182fafc 3f80c040 48234c6d 3bc0fff0 3b9c5ed0 4bfffaf4 81290020
712a0004
[0.418825] 4182fb34 48234c51 4bfffb2c 81230004 <80690130> 4e800020 7c0802a6
9421ffe0
[0.426763] ---[ end trace fe4113ee21d72ffa ]---
fixes: e65078f1f3490 ("powerpc: sysdev: cpm1: use gpiochip data pointer")
fixes: a14a2d484b386 ("powerpc: cpm_common: use gpiochip data pointer")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
arch/powerpc/sysdev/cpm1.c | 6 --
arch/powerpc/sysdev/cpm_common.c | 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index 6c11099..81d4947 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -534,7 +534,8 @@ struct cpm1_gpio16_chip {
static void cpm1_gpio16_save_regs(struct of_mm_gpio_chip *mm_gc)
{
- struct cpm1_gpio16_chip *cpm1_gc = gpiochip_get_data(&mm_gc->gc);
+ struct cpm1_gpio16_chip *cpm1_gc =
+ container_of(mm_gc, struct cpm1_gpio16_chip, mm_gc);
struct cpm_ioport16 __iomem *iop = mm_gc->regs;
cpm1_gc->cpdata = in_be16(&iop->dat);
@@ -649,7 +650,8 @@ struct cpm1_gpio32_chip {
static void cpm1_gpio32_save_regs(struct of_mm_gpio_chip *mm_gc)
{
- struct cpm1_gpio32_chip *cpm1_gc = gpiochip_get_data(&mm_gc->gc);
+ struct cpm1_gpio32_chip *cpm1_gc =
+ container_of(mm_gc, struct cpm1_gpio32_chip, mm_gc);
struct cpm_ioport32b __iomem *iop = mm_gc->regs;
cpm1_gc->cpdata = in_be32(&iop->dat);
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index 911456d..947f420 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -94,7 +94,8 @@ struct cpm2_gpio32_chip {
static void cpm2_gpio32_save_regs(struct of_mm_gpio_chip *mm_gc)
{
- struct cpm2_gpio32_chip *cpm2_gc = gpiochip_get_data(&mm_gc->gc);
+ struct cpm2_gpio32_chip *cpm2_gc =
+ container_of(mm_gc, struct cpm2_gpio32_chip, mm_gc);
struct cpm2_ioports __iomem *iop = mm_gc->regs;
cpm2_gc->cpdata = in_be32(&iop->dat);
--
2.1.0
Re: [PATCH] usb: core: Add runtime resume checking
On Thu, Aug 11, 2016 at 04:41:27PM +0800, Baolin Wang wrote: > >> >> > >> >> OK. But that is a real problem. It will pm_runtime_resume() falied > >> >> (issued in choose_wakeup()), cause usb controller has powered-off and > >> >> xHCI controller has suspended and we have no method to notify the user > >> >> to power-on USB controller. Any good suggestion to solve this, Alan > >> >> and Peter? Thanks. > >> >> > >> > > >> > Maybe you can show us the call stack why pm_runtime_resume has failed > >> > at your environment. > >> > >> OK. I try to explain it at below: > >> > >> For example: No slave attached> usb interface runtime suspend > >> > usb device runtime suspend (routine is: > >> usb_suspend_device()--->generic_suspend() --> hcd_bus_suspend()--> > >> xhci_bus_suspend()) -> xhci_ suspend() -> power off usb > >> controller. After that if the system wants to enter suspend state, > >> then it also will issue usb_dev_suspend(), then the > >> pm_runtime_resume() function (issued in choose_wakeup() function) will > >> return -ESHUTDOWN due to xhci has been suspend and hardware is not > >> accessible. > >> > >> We issue the pm_runtime_resume() function routine: usb_resume_device() > >> > generic_resume() > hcd_bus_resume() ---> xhci_bus_resume(), > >> but now xHCI is not accessible due to xhci_suspend() is issued and USB > >> controller is power off when no slave attached. That is why > >> pm_runtime_resume failed. > >> > > > > What host controller driver you are using? Assume you are using > > xhci-plat.c. The problem for you is this driver does not implement > > Yes. I use xhci-plat.c. > > > runtime pm operations, so the flag HCD_FLAG_HW_ACCESSIBLE is not set. > > Maybe Robert's patch is a good start for you [1] > > > > [1] http://www.spinics.net/lists/linux-usb/msg144602.html > > OK. Maybe I need to implement the runtime PM callbacks for xhci-plat, right? > I think so. -- Best Regards, Peter Chen
Re: [PATCH v2 0/5] Allow the trampoline to use EFI boot services RAM
* Andy Lutomirski wrote: > On Aug 10, 2016 3:31 PM, "Ingo Molnar" wrote: > > > > > > One side note: > > > > * Andy Lutomirski wrote: > > > > > This series fixes it the other way: it allow the trampoline to live > > > in boot services memory. It achieves this by deferring the panic > > > due to failure to reserve a trampoline until early_initcall time > > > and then adjusting the EFI boot services quirk to reserve space > > > for the trampoline if we haven't already found it a home. > > > > > x86/efi: Allocate a trampoline if needed in efi_free_boot_services() > > > > Btw., this means that we first try to allocate the trampoline the old > > fashioned > > way, and in the rare cases this fails we allocate it from the EFI data area, > > right? > > Yes, exactly. > > > > > This is problematic from the probability management POV: we are creating a > > rare > > piece of code that will run only on a select few systems. > > > > I think it would be much better to allocate the trampoline from the EFI > > area on > > all EFI systems by default. Is there any reason why that would not work? > > I think most EFI systems don't have any boot services below 1MB, so > that wouldn't work. > > We could try allocating from EFI more generically, but that sounds > much scarier. The EFI memory map code is tangled with the e820 code > and the memblock code, and I'd be nervous about confusing the e820 > code or accidentally allocating blacklisted RAM (EBDA, > Sandybridge-quirked, etc.) The code I wrote should only allocate the > trampoline at a different address than current kernels in cases where > current kernels would panic. > > I don't like it either, but after scratching my head for a while I > didn't come up with anything better. At least the actual special case > is only a couple lines of code. Ok, fine enough to me! Matt, is patch #5: [PATCH v2 5/5] x86/efi: Allocate a trampoline if needed in efi_free_boot_services() looking good to you? Thanks, Ingo
Re: [PATCH V3] clk: bcm: Add driver for Northstar ILP clock
On 10 August 2016 at 20:21, Jon Mason wrote:
> On Wed, Aug 10, 2016 at 1:44 PM, Ray Jui wrote:
>> On 8/10/2016 10:28 AM, Rafał Miłecki wrote:
>>>
>>> On 10 August 2016 at 19:22, Jon Mason wrote:
On Wed, Aug 10, 2016 at 8:05 AM, Rafał Miłecki wrote:
>
> diff --git a/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
> b/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
> new file mode 100644
> index 000..a18c73f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
> @@ -0,0 +1,40 @@
> +Broadcom Northstar ILP clock
> +
> +
> +This binding uses the common clock binding:
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +This binding is used for ILP clock (sometimes referred as "slow clock")
> +on Broadcom Northstar devices using Corex-A7 CPU.
> +
> +This clock is part of PMU (Power Management Unit), a Broadcom's device
> +handing power-related aspects. Please note PMU contains more
> subdevices,
> +ILP is only one of them.
> +
> +ILP's rate has to be calculated on runtime and it depends on ALP clock
> +which has to be referenced.
> +
> +Required properties:
> +- compatible: "brcm,ns-ilp"
> +- reg: iomem address range of PMU (Power Management Unit)
> +- reg-names: "pmu", the only needed & supported reg right now
> +- clocks: has to reference an ALP clock
> +- #clock-cells: should be <0>
> +
> +Example:
> +
> +pmu@18012000 {
> + compatible = "simple-bus";
> + ranges = <0x 0x18012000 0x1000>;
I don't see a corresponding DT entry in this patch, but 18012000 is
the PCI block. So, I am concerned this will collide if used there.
I looked at the NS register reference guide, and I cannot find the
registers you are trying to reference. Is this supposed to be
referencing the LCPLL clock registers in DMU? If so, there is already
a driver in there for this (see drivers/clk/bcm/clk-nsp.c).
>>>
>>>
>>> This patch is for BCM53573 family, not BCM4708 family you are looking at.
>>>
>>> Found chip with id 53573, rev 0x02 and package 0x01
>>> Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x36, class 0x0)
>>> Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x38, class 0x0)
>>> Core 2 found: PCIe Gen 2 (manuf 0x4BF, id 0x501, rev 0x05, class 0x0)
>>> Core 3 found: ARM CA7 (manuf 0x4BF, id 0x847, rev 0x00, class 0x0)
>>> Core 4 found: USB 2.0 Host (manuf 0x4BF, id 0x819, rev 0x05, class 0x0)
>>> Core 5 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x08, class 0x0)
>>> Core 6 found: I2S (manuf 0x4BF, id 0x834, rev 0x06, class 0x0)
>>> Core 7 found: CNDS DDR2/3 memory controller (manuf 0x4BF, id 0x846,
>>> rev 0x00, class 0x0)
>>> Core 8 found: NAND flash controller (manuf 0x4BF, id 0x509, rev 0x01,
>>> class 0x0)
>>> Core 9 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x38, class 0x0)
>>> Core 10 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x08, class 0x0)
>>> Core 11 found: I2S (manuf 0x4BF, id 0x834, rev 0x06, class 0x0)
>>> Core 12 found: GCI (manuf 0x4BF, id 0x840, rev 0x08, class 0x0)
>>> Core 13 found: PMU (manuf 0x4BF, id 0x827, rev 0x1C, class 0x0)
>>>
>>
>> Out of curiosity, I searched the datasheet and found this is a wireless
>> router SoC done by the WLAN team. It happens to share some peripherals with
>> other iProc based SoCs.
>>
>> I cannot find a code name for this SoC from our internal documents. I guess
>> that name "Northstar" used here has confused both Jon and me.
>
> Ray is right. I just spoke to one of the people here with knowledge
> of the HW, and this is not related at all to the 4708/9/5301X. It MAY
> have some of the same peripherals, but the core is different (Cortex
> A7 instead of A9).
>
> I think we are best off to change the name and turn this into a
> separate device tree, driver base, etc. I wasn't able to get a code
> name, so perhaps simply call it "BCM53573".
Yes, I said clearly it uses Corex-A7 in the commit message and
Documentation entry.
Florian already shared his doubts about BCM53573 belonging to the
Northstar, but I found out [1] that your (Broadcom's) SDK treats it as
Northstar device:
Asus RT-AC1200G+
# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 1795.68
Features : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
Hardware : Northstar Prototype
Revision :
Serial :
It seems Broadcom's WLAN team claims it's a Northstar and you claim
it's not. Could you discuss this internally and let us know, please?
[1] https://lkml.org/lkml/2016/7/29/345
--
Rafał
Architectural-Queries on integrating Sierra-MC8090 with Linux
Hi All. Have posted the question on Sierra-forums https://forum.sierrawireless.com/viewtopic.php?f=117&t=9898 Posting it here as well, as the activity there is relatively low, and this is where all the kernel-guys hand :) I am using a Ubuntu interfaced with a Sierra-MC8090 module. Right now MC8090 is identifed as a network-interface on Linux, made possible by the usage of "sierra" (serial-driver) and "sierra_net" (direct-ip usb-to-wwan driver) kernel-drivers. This "mostly" works, except that we, in the user-application, are not able to access the serial-file /dev/ttyUSB3 (this file is in constant usage by /usr/sbin/ModemManager). Now, my question is, if we disable loading the "sierra_net" driver, and use just "sierra" driver to communicate on the serial-port, will using the Sierra-Linux-QMI-SDK do the job? In particular, * I understand that we will now have exclusive access (please correct me if I am wrong) to the serial-port /dev/ttyUSB3. * How to do we create a socket to a particular server-port using the QMI-SDK? I can see in the examples that we can start a data-call for a profile (ConnectGSM.c), but I am unable to find how to instantiate a socket through which we can do regular reads/writes. Will be grateful to hear back from someone. Thanks and Regards, Ajay
Re: [PATCH v4 3/4] drm/mediatek: Add gamma correction.
On Thu, Aug 11, 2016 at 11:02:27AM +0300, Ville Syrjälä wrote:
> On Thu, Aug 11, 2016 at 09:51:16AM +0200, Philipp Zabel wrote:
> > Am Donnerstag, den 11.08.2016, 10:44 +0300 schrieb Ville Syrjälä:
> > > On Thu, Aug 11, 2016 at 09:32:59AM +0200, Philipp Zabel wrote:
> > > > Am Donnerstag, den 28.07.2016, 10:22 +0800 schrieb Bibby Hsieh:
> > > > > Add gamma set function to correct brightness values.
> > > > > It applies arbitrary mapping curve to compensate the
> > > > > incorrect transfer function of the panel.
> > > > >
> > > > > Signed-off-by: Bibby Hsieh
> > > > > ---
> > > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c |8 ++-
> > > > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 31
> > > > > +++
> > > > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 10 +
> > > > > 4 files changed, 49 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > > index 24aa3ba..cbb460a5 100644
> > > > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > > > @@ -409,6 +409,9 @@ static void mtk_drm_crtc_atomic_flush(struct
> > > > > drm_crtc *crtc,
> > > > > }
> > > > > if (pending_planes)
> > > > > mtk_crtc->pending_planes = true;
> > > > > + if (crtc->state->color_mgmt_changed)
> > > > > + for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > > > > + mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i],
> > > > > crtc->state);
> > > > > }
> > > > >
> > > > > static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > > > > @@ -418,6 +421,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs
> > > > > = {
> > > > > .reset = mtk_drm_crtc_reset,
> > > > > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > > > > .atomic_destroy_state = mtk_drm_crtc_destroy_state,
> > > > > + .gamma_set = drm_atomic_helper_legacy_gamma_set,
> > > > > };
> > > > >
> > > > > static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > > > > @@ -568,7 +572,9 @@ int mtk_drm_crtc_create(struct drm_device
> > > > > *drm_dev,
> > > > > &mtk_crtc->planes[1].base, pipe);
> > > > > if (ret < 0)
> > > > > goto unprepare;
> > > > > -
> > > > > + drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
> > > > > + drm_helper_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
> > > > > + MTK_LUT_SIZE);
> > > >
> > > > I have applied all four patches and rebased onto v4.8-rc1, replacing
> > > > drm_helper_crtc_enable_color_mgmt with:
> > > >
> > > > drm_crtc_enable_color_mgmt(&mtk_crtc->base, MTK_LUT_SIZE,
> > > >true, MTK_LUT_SIZE);
> > >
> > > BTW that looks wrong (already in the original). AFAICS the patch just
> > > handled the gamma_lut, not the degamma_lut, so telling you have both
> > > is not right.
> >
> > Thanks, so should that be
> >drm_crtc_enable_color_mgmt(&mtk_crtc->base, 0, false,
> > MTK_LUT_SIZE);
> > instead, since we only handle gamma?
>
> Hmm. Yeah, that looks correct since you didn't seem to have "ctm" either.
Yup, that's how this is meant to be used.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 0/7] drm/mediatek: cleaning up and refine
On Thu, Aug 11, 2016 at 09:33:26AM +0200, Philipp Zabel wrote: > Am Donnerstag, den 04.08.2016, 10:59 +0800 schrieb Bibby Hsieh: > > These patches based on 4.7-rc1 to clean up unused function > > & variable and use drm core function instead. > > > > The following patches are needed to cleanly apply on top of v4.7-rc1: > > - https://patchwork.kernel.org/patch/8044001/ > >(drm: Deal with rotation in drm_plane_helper_check_update()) > > - https://patchwork.kernel.org/patch/9248373/ > >(drm: Warn about negative sizes when calculating scale factor) > > - https://patchwork.kernel.org/patch/9248371/ > >(drm: Store clipped src/dst coordinatee in drm_plane_state) > > - https://patchwork.kernel.org/patch/9248363/ > >(drm/plane-helper: Add drm_plane_helper_check_state()) > > - https://patchwork.kernel.org/patch/9248361/ > >(drm/mediatek: Use drm_plane_helper_check_state()) > > > > Bibby Hsieh (2): > > drm/mediatek: Use drm_atomic destroy_state helpers > > drm/mediatek: Fix mtk_atomic_complete for runtime_pm > > > > Daniel Kurtz (5): > > drm/mediatek: Remove mtk_drm_crtc_check_flush > > drm/mediatek: plane: Remove plane zpos/index > > drm/mediatek: Remove mtk_drm_plane > > I have picked up patches 1-5, but not patches 6-7: > > > drm/mediatek: plane: Merge mtk_plane_enable into > > mtk_plane_atomic_update > > drm/mediatek: plane: Use FB's format's cpp to compute x offset > > These two don't apply. Could you please rebase them onto > git.pengutronix.de/git/pza/linux.git mediatek-drm/next Note that I think most of them are already in drm-misc, and that branch is non-rebasing. -Daniel > > regards > Philipp > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] x86/efi-bgrt: remove the check of the version field
* Icenowy Zheng wrote: > > > 10.08.2016, 20:52, "Ingo Molnar" : > > * Icenowy Zheng wrote: > > > >> Some broken firmwares have a wrongly filled version field in BGRT table. > >> (See http://wiki.osdev.org/Broken_UEFI_implementations ) > >> > >> As we know, these firmwares can also provide correct BGRT image, although > >> the table is wrong. > >> > >> After removing the check of the version field, the kernel can now extract > >> the image correctly, and the information is also correct. > >> > >> Tested on a Thinkpad E531 (68854UC). > > > > What's the practical effects of the bug - what problems does a missing > > /sys/firmware/acpi/bgrt/ cause? > > Currently nothing uses this featues. However, one of my friend is trying to > develop a splash screen which uses ACPI BGRT, like the splash screen > of Windows 8 and above. > Without the directory, there won't be any way to retrieve the vendor splash > logo. Ok - please add this information to the changelog. Acked-by: Ingo Molnar Thanks, Ingo
Re: [PATCH 05/19] arm64: rename COMPAT to AARCH32_EL0 in Kconfig
On Thursday, August 11, 2016 3:35:01 PM CEST Zhangjian (Bamvor) wrote:
> On 2016/6/18 7:54, Yury Norov wrote:
> > From: Andrew Pinski
> >
> > In this patchset ILP32 ABI support is added. Additionally to AARCH32,
> > which is binary-compatible with ARM, ILP32 is (mostly) ABI-compatible.
> >
> > From now, AARCH32_EL0 (former COMPAT) config option means the support of
> > AARCH32 userspace, ARM64_ILP32 - support of ILP32 ABI (see next patches),
> > and COMPAT indicates that one of them, or both, is enabled.
> >
> > Where needed, CONFIG_COMPAT is changed over to use CONFIG_AARCH32_EL0
> > instead
> >
> > Reviewed-by: David Daney
> > Signed-off-by: Andrew Pinski
> > Signed-off-by: Philipp Tomsich
> > Signed-off-by: Christoph Muellner
> > Signed-off-by: Bamvor Jian Zhang
> > Signed-off-by: Yury Norov
> ...
> > diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> > index c173d32..af200a8 100644
> > --- a/arch/arm64/kernel/cpuinfo.c
> > +++ b/arch/arm64/kernel/cpuinfo.c
> > @@ -134,15 +134,17 @@ static int c_show(struct seq_file *m, void *v)
> > */
> > seq_puts(m, "Features\t:");
> > if (compat) {
> > -#ifdef CONFIG_COMPAT
> > - for (j = 0; compat_hwcap_str[j]; j++)
> > - if (compat_elf_hwcap & (1 << j))
> > - seq_printf(m, " %s",
> > compat_hwcap_str[j]);
> > -
> > - for (j = 0; compat_hwcap2_str[j]; j++)
> > - if (compat_elf_hwcap2 & (1 << j))
> > - seq_printf(m, " %s",
> > compat_hwcap2_str[j]);
> > -#endif /* CONFIG_COMPAT */
> > +#ifdef CONFIG_AARCH32_EL0
> I saw that compat_hwcap_str and compat_hwcap2_str is defined when
> "CONFIG_COMPAT" is true. Why we only change it to CONFIG_AARCH32_EL0
> in c show()?
> > + if (personality(current->personality) == PER_LINUX32) {
> And "compat" is "personality(current->personality) == PER_LINUX32;",
> it seems that there is no need to add this twice.
I think it would be best to remove the #ifdef here completely,
the PER_LINUX32 concept is not strictly tied to the emulation
of ARM binaries, it literally just changes the output of
/proc/cpuinfo and 'uname', and you can have ARM binaries with
PER_LINUX (using the arm64 uname) just like you can have
arm64 binaries running with PER_LINUX32.
Arnd
Re: [REGRESSION] 362899b ("macvtap: switch to use skb array") causes oops during teardown
On 2016年08月11日 16:13, Cornelia Huck wrote:
On Thu, 11 Aug 2016 15:49:12 +0800
Jason Wang wrote:
This looks like a use-after-free. Could you pls try the following patch
to see it if fixes your issue?
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index a38c0da..070e329 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -275,7 +275,6 @@ static void macvtap_put_queue(struct macvtap_queue *q)
rtnl_unlock();
synchronize_rcu();
- skb_array_cleanup(&q->skb_array);
sock_put(&q->sk);
}
@@ -533,10 +532,8 @@ static void macvtap_sock_write_space(struct sock *sk)
static void macvtap_sock_destruct(struct sock *sk)
{
struct macvtap_queue *q = container_of(sk, struct
macvtap_queue, sk);
- struct sk_buff *skb;
- while ((skb = skb_array_consume(&q->skb_array)) != NULL)
- kfree_skb(skb);
+ skb_array_cleanup(&q->skb_array);
}
static int macvtap_open(struct inode *inode, struct file *file)
Yes, that change fixes things for me.
Tested-by: Cornelia Huck
Thanks for the quick reply!
Thanks for the testing.
Will send a formal patch shortly.
Re: [PATCH RESEND] net: can: Introduce MEN 16Z192-00 CAN controller driver
On Thu, Aug 11, 2016 at 10:45:00AM +0200, Oliver Hartkopp wrote: > On 08/11/2016 09:14 AM, Andreas Werner wrote: > >On Wed, Aug 10, 2016 at 10:28:45PM +0200, Oliver Hartkopp wrote: > > >>Just check 'git grep IFF_ECHO'. Even grcan.c and janz-ican3.c have IFF_ECHO > >>set - but implement it in a different way without using the provided > >>machanism from dev.c . > >> > > > >Ok I am with you. > > Great :-) > > >>A local loopback inside the CAN controller which is generated after > >>successful transmit is an excellent implementation with excellent > >>timestamps. The only problem for you is to detect the looped CAN frames and > >>match them to the skb pointer of the outgoing frame to 'receive' the correct > >>echo skb. > >> > > > >At the moment, i think there is no way to detect those looped frames. > >I will talk to our IC designer and discuss this issue with him. Maybe we > >have the possibility to get a local loopback inside the CAN controller. > >This seems to be the best way to do it. > > When you still have the possibility to change the IP core I would suggest to > create some kind of 16/32 bit value which you can pass to the CAN controller > along with the CAN frame to be sent. > > And when this frame comes back due to the loopback you can use this non-zero > 16/32 bit value to match into a list of tx skb pointers for IFF_ECHO. > > E.g. when this 16/32 bit value is zero this CAN frame obviously was received > from another CAN node. > > Just an idea. > I am not sure if we have a way to change the IP but i will try to talk with my IC designer. He will be available next week. Your idea sounds good. I will check a few more driver to get more information how they did the implementation. > Regards, > Oliver Thanks your comments and explanations Oliver. Regards Andy
Re: [PATCH 1/9] kconfig: tinyconfig: provide whole choice blocks to avoid warnings
* Arnd Bergmann wrote: > Using "make tinyconfig" produces a couple of annoying warnings that show up > for build test machines all the time: > > .config:966:warning: override: NOHIGHMEM changes choice state > .config:965:warning: override: SLOB changes choice state > .config:963:warning: override: KERNEL_XZ changes choice state > .config:962:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state > .config:933:warning: override: SLOB changes choice state > .config:930:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state > .config:870:warning: override: SLOB changes choice state > .config:868:warning: override: KERNEL_XZ changes choice state > .config:867:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state > > I've made a previous attempt at fixing them and we discussed a number of > alternatives. > > I tried changing the Makefile to use "merge_config.sh -n $(fragment-list)" > but couldn't get that to work properly. > > This is yet another approach, based on the observation that we do want > to see a warning for conflicting 'choice' options, and that we can simply > make them non-conflicting by listing all other options as disabled. > This is a trivial patch that we can apply independent of plans for other > changes. > > Signed-off-by: Arnd Bergmann > Link: https://storage.kernelci.org/mainline/v4.7-rc6/x86-tinyconfig/build.log > https://patchwork.kernel.org/patch/9212749/ > Reviewed-by: Josh Triplett > Cc: Masahiro Yamada > Cc: Andrew Morton > --- > This version incorporates feedback from Masahiro Yamada, and includes > the x86 change that Josh mentioned > > Unlike the other patches in this series, this is not a recent regression, > but it is the only non-regression warning fix I'm aware of that we > currently need for a clean build on all configurations tested by > https://kernelci.org/. > --- > arch/x86/configs/tiny.config | 2 ++ > kernel/configs/tiny.config | 8 > 2 files changed, 10 insertions(+) > > diff --git a/arch/x86/configs/tiny.config b/arch/x86/configs/tiny.config > index 4e2ecfa23c15..4b429df40d7a 100644 > --- a/arch/x86/configs/tiny.config > +++ b/arch/x86/configs/tiny.config > @@ -1 +1,3 @@ > CONFIG_NOHIGHMEM=y > +# CONFIG_HIGHMEM4G is not set > +# CONFIG_HIGHMEM64G is not set Acked-by: Ingo Molnar Thanks, Ingo
[PATCH 0/4] net: hix5hd2_gmac: add tx sg feature and reset/clock control signals
The "hix5hd2" is SoC name, add the generic ethernet driver name. The "hisi-gemac-v1" is the basic version and "hisi-gemac-v2" adds the SG/TXCSUM/TSO/UFO features. This patch set only adds the SG(scatter-gather) driver for transmitting, the drivers of other features will be submitted later. Add the MAC reset control signals and clock signals. As a result, the hix5hd2 ethernet clock can be abstracted as gate clock instead of self defined complex clock. Dongpo Li (2): clk: hix5hd2: change ethernet clock type ARM: dts: hix5hd2: add gmac clock and reset property Li Dongpo (2): net: hix5hd2_gmac: add tx scatter-gather feature net: hix5hd2_gmac: add reset control and clock signals .../bindings/net/hisilicon-hix5hd2-gmac.txt| 25 +- arch/arm/boot/dts/hisi-x5hd2-dkb.dts | 2 + arch/arm/boot/dts/hisi-x5hd2.dtsi | 15 +- drivers/clk/hisilicon/clk-hix5hd2.c| 72 + drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 353 +++-- include/dt-bindings/clock/hix5hd2-clock.h | 6 +- 6 files changed, 381 insertions(+), 92 deletions(-) -- 2.8.2
[PATCH 2/4] net: hix5hd2_gmac: add reset control and clock signals
From: Li Dongpo
Add three reset control signals, "mac_core_rst", "mac_ifc_rst" and
"phy_rst".
The following diagram explained how the reset signals work.
SoC
|-
| --|
| | cpu | |
| --|
| | |
| AMBA bus |
| GMAC | |
|-- |
| - mac_core_rst | -- | |
| |clock and |-->| mac core | | |
| |reset | | -- | |
| |generator | | | | |
| - || | |
| |-->| mac interface | | |
| | mac_ifc_rst | | |
| | | | | |
| | | -- | |
| |phy_rst | | RGMII interface | | |
| | | -- | |
| | -- |
|--|--|
| |
| --
|- |PHY chip |
--
The "mac_core_rst" represents "mac core reset signal", it resets
the mac core including packet processing unit, descriptor processing unit,
tx engine, rx engine, control unit.
The "mac_ifc_rst" represents "mac interface reset signal", it resets
the mac interface. The mac interface unit connects mac core and
data interface like MII/RMII/RGMII. After we set a new value of
interface mode, we must reset mac interface to reload the new mode value.
The "phy_rst" represents "phy reset signal", it does a hardware reset
on the PHY chip. This reset signal is optinal if the PHY can work well
without the hardware reset.
Add one more clock signal, the existing is MAC core clock,
and the new one is MAC interface clock.
Signed-off-by: Dongpo Li
---
.../bindings/net/hisilicon-hix5hd2-gmac.txt| 16 ++-
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 140 +++--
2 files changed, 143 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
index 3c02fac..a0bf2ca 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
@@ -17,6 +17,16 @@ Required properties:
- phy-handle: see ethernet.txt [1].
- mac-address: see ethernet.txt [1].
- clocks: clock phandle and specifier pair.
+- clock-names: contain the clock name "mac_core" and "mac_ifc".
+- resets: should contain the phandle to the MAC core reset signal(required),
+ the MAC interface reset signal(required)
+ and the PHY reset signal(optional).
+- reset-names: contain the reset signal name "mac_core"(required),
+ "mac_ifc"(required) and "phy"(optional).
+- hisilicon,phy-reset-delays-us: triplet of delays if PHY reset signal given.
+ The 1st cell is reset pre-delay in micro seconds.
+ The 2nd cell is reset pulse in micro seconds.
+ The 3rd cell is reset post-delay in micro seconds.
- PHY subnode: inherits from phy binding [2]
@@ -33,7 +43,11 @@ Example:
phy-mode = "mii";
phy-handle = <&phy2>;
mac-address = [00 00 00 00 00 00];
- clocks = <&clock HIX5HD2_MAC0_CLK>;
+ clocks = <&clock HIX5HD2_MAC0_CLK>, <&clock
HIX5HD2_MAC_IFC0_CLK>;
+ clock-names = "mac_core", "mac_ifc";
+ resets = <&clock 0xcc 8>, <&clock 0xcc 10>, <&clock 0x120 4>;
+ reset-names = "mac_core", "mac_ifc", "phy";
+ hisilicon,phy-reset-delays-us = <1 1 3>;
phy2: ethernet-phy@2 {
reg = <2>;
diff --git a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
index 679a5e5..11e70bb 100644
--- a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -197,6 +198,15 @@
#define GEMAC_V2 (GEMAC_V1 | HW_CAP_TSO)
#define HAS_CAP_TSO(hw_cap)((hw_cap) & HW_CAP_TSO)
+#define PHY_RESET_DELAYS_PROPERTY "hisilicon,phy-reset-delays-us"
+
+enum phy_reset_delays {
+ PRE_DELAY,
+ PULSE,
+ POST_DELAY,
+ DELAYS_NUM,
+};
+
struct hix5hd2_desc {
__le32 buff_addr;
__le32 cmd;
@@ -255,12 +265,23 @@ struct hix5hd2_p
[PATCH 3/4] clk: hix5hd2: change ethernet clock type
Because the clock and reset signals share the same register,
we initialize reset controller when initializing clock controller.
So the ethernet driver will control the reset signal instead of
the clock driver.
All the ethernet clock is changed from complex clock to gate clock.
The original ethernet clock is really a "complex" clock because
it's obscure and hard to understand.
Signed-off-by: Dongpo Li
---
drivers/clk/hisilicon/clk-hix5hd2.c | 72 +++
include/dt-bindings/clock/hix5hd2-clock.h | 6 ++-
2 files changed, 20 insertions(+), 58 deletions(-)
diff --git a/drivers/clk/hisilicon/clk-hix5hd2.c
b/drivers/clk/hisilicon/clk-hix5hd2.c
index 14b05ef..f9689e3 100644
--- a/drivers/clk/hisilicon/clk-hix5hd2.c
+++ b/drivers/clk/hisilicon/clk-hix5hd2.c
@@ -12,6 +12,7 @@
#include
#include
#include "clk.h"
+#include "reset.h"
static struct hisi_fixed_rate_clock hix5hd2_fixed_rate_clks[] __initdata = {
{ HIX5HD2_FIXED_1200M, "1200m", NULL, 0, 12, },
@@ -93,8 +94,12 @@ static struct hisi_gate_clock hix5hd2_gate_clks[] __initdata
= {
/* gsf */
{ HIX5HD2_FWD_BUS_CLK, "clk_fwd_bus", NULL, 0, 0xcc, 0, 0, },
{ HIX5HD2_FWD_SYS_CLK, "clk_fwd_sys", "clk_fwd_bus", 0, 0xcc, 5, 0, },
- { HIX5HD2_MAC0_PHY_CLK, "clk_fephy", "clk_fwd_sys",
-CLK_SET_RATE_PARENT, 0x120, 0, 0, },
+ { HIX5HD2_MAC0_CLK, "clk_mac0", "clk_fwd_sys", 0, 0xcc, 1, 0, },
+ { HIX5HD2_MAC_IFC0_CLK, "clk_mac_ifc0", "clk_fwd_sys", 0, 0xcc, 3, 0, },
+ { HIX5HD2_MAC1_CLK, "clk_mac1", "clk_fwd_sys", 0, 0xcc, 2, 0, },
+ { HIX5HD2_MAC_IFC1_CLK, "clk_mac_ifc1", "clk_fwd_sys", 0, 0xcc, 4, 0, },
+ { HIX5HD2_MAC0_PHY_CLK, "clk_fephy", NULL,
+CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0x120, 0, 0, },
/* wdg0 */
{ HIX5HD2_WDG0_CLK, "clk_wdg0", "24m",
CLK_SET_RATE_PARENT, 0x178, 0, 0, },
@@ -129,7 +134,6 @@ static struct hisi_gate_clock hix5hd2_gate_clks[]
__initdata = {
enum hix5hd2_clk_type {
TYPE_COMPLEX,
- TYPE_ETHER,
};
struct hix5hd2_complex_clock {
@@ -157,10 +161,6 @@ struct hix5hd2_clk_complex {
};
static struct hix5hd2_complex_clock hix5hd2_complex_clks[] __initdata = {
- {"clk_mac0", "clk_fephy", HIX5HD2_MAC0_CLK,
- 0xcc, 0xa, 0x500, 0x120, 0, 0x10, TYPE_ETHER},
- {"clk_mac1", "clk_fwd_sys", HIX5HD2_MAC1_CLK,
- 0xcc, 0x14, 0xa00, 0x168, 0x2, 0, TYPE_ETHER},
{"clk_sata", NULL, HIX5HD2_SATA_CLK,
0xa8, 0x1f, 0x300, 0xac, 0x1, 0x0, TYPE_COMPLEX},
{"clk_usb", NULL, HIX5HD2_USB_CLK,
@@ -169,50 +169,6 @@ static struct hix5hd2_complex_clock hix5hd2_complex_clks[]
__initdata = {
#define to_complex_clk(_hw) container_of(_hw, struct hix5hd2_clk_complex, hw)
-static int clk_ether_prepare(struct clk_hw *hw)
-{
- struct hix5hd2_clk_complex *clk = to_complex_clk(hw);
- u32 val;
-
- val = readl_relaxed(clk->ctrl_reg);
- val |= clk->ctrl_clk_mask | clk->ctrl_rst_mask;
- writel_relaxed(val, clk->ctrl_reg);
- val &= ~(clk->ctrl_rst_mask);
- writel_relaxed(val, clk->ctrl_reg);
-
- val = readl_relaxed(clk->phy_reg);
- val |= clk->phy_clk_mask;
- val &= ~(clk->phy_rst_mask);
- writel_relaxed(val, clk->phy_reg);
- mdelay(10);
-
- val &= ~(clk->phy_clk_mask);
- val |= clk->phy_rst_mask;
- writel_relaxed(val, clk->phy_reg);
- mdelay(10);
-
- val |= clk->phy_clk_mask;
- val &= ~(clk->phy_rst_mask);
- writel_relaxed(val, clk->phy_reg);
- mdelay(30);
- return 0;
-}
-
-static void clk_ether_unprepare(struct clk_hw *hw)
-{
- struct hix5hd2_clk_complex *clk = to_complex_clk(hw);
- u32 val;
-
- val = readl_relaxed(clk->ctrl_reg);
- val &= ~(clk->ctrl_clk_mask);
- writel_relaxed(val, clk->ctrl_reg);
-}
-
-static struct clk_ops clk_ether_ops = {
- .prepare = clk_ether_prepare,
- .unprepare = clk_ether_unprepare,
-};
-
static int clk_complex_enable(struct clk_hw *hw)
{
struct hix5hd2_clk_complex *clk = to_complex_clk(hw);
@@ -269,10 +225,7 @@ hix5hd2_clk_register_complex(struct hix5hd2_complex_clock
*clks, int nums,
return;
init.name = clks[i].name;
- if (clks[i].type == TYPE_ETHER)
- init.ops = &clk_ether_ops;
- else
- init.ops = &clk_complex_ops;
+ init.ops = &clk_complex_ops;
init.flags = CLK_IS_BASIC;
init.parent_names =
@@ -302,10 +255,17 @@ hix5hd2_clk_register_complex(struct hix5hd2_complex_clock
*clks, int nums,
static void __init hix5hd2_clk_init(struct device_node *np)
{
struct hisi_clock_data *clk_data;
+ struct hisi_reset_controller *rstc;
+
+ rstc = hisi_reset_init(np);
+ if (!rstc)
+ return;
clk_data = hisi_clk_
