Re: [PATCH] block: fix unintended fallthrough in generic_make_request_checks()
Oops, thanks for the fix: Reviewed-by: Christoph Hellwig
Re: [PATCH] mm, vmscan: add cond_resched into shrink_node_memcg
> > Hi, > there were multiple reportes of the similar RCU stalls. Only Boris has > confirmed that this patch helps in his workload. Others might see a > slightly different issue and that should be investigated if it is the > case. As pointed out by Paul [1] cond_resched might be not sufficient > to silence RCU stalls because that would require a real scheduling. > This is a separate problem, though, and Paul is working with Peter [2] > to resolve it. > > Anyway, I believe that this patch should be a good start because it > really seems that nr_taken=0 during the LRU isolation can be triggered > in the real life. All reporters are agreeing to start seeing this issue > when moving on to 4.8 kernel which might be just a coincidence or a > different behavior of some subsystem. Well, MM has moved from zone to > node reclaim but I couldn't have found any direct relation to that > change. > > [1] http://lkml.kernel.org/r/20161130142955.gs3...@linux.vnet.ibm.com > [2] http://lkml.kernel.org/r/20161201124024.gb3...@linux.vnet.ibm.com > > mm/vmscan.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index c05f00042430..c4abf08861d2 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2362,6 +2362,8 @@ static void shrink_node_memcg(struct pglist_data > *pgdat, struct mem_cgroup *memc > } > } > > + cond_resched(); > + I see a cond_resched_rcu_qs() as a part of linux next inside the while (nr[..]) loop. Do we need this as well? Balbir Singh.
Re: [PATCH] mm, vmscan: add cond_resched into shrink_node_memcg
[CC Paul - sorry I've tried to save you from more emails...] On Mon 05-12-16 23:44:27, Balbir Singh wrote: > > > > Hi, > > there were multiple reportes of the similar RCU stalls. Only Boris has > > confirmed that this patch helps in his workload. Others might see a > > slightly different issue and that should be investigated if it is the > > case. As pointed out by Paul [1] cond_resched might be not sufficient > > to silence RCU stalls because that would require a real scheduling. > > This is a separate problem, though, and Paul is working with Peter [2] > > to resolve it. > > > > Anyway, I believe that this patch should be a good start because it > > really seems that nr_taken=0 during the LRU isolation can be triggered > > in the real life. All reporters are agreeing to start seeing this issue > > when moving on to 4.8 kernel which might be just a coincidence or a > > different behavior of some subsystem. Well, MM has moved from zone to > > node reclaim but I couldn't have found any direct relation to that > > change. > > > > [1] http://lkml.kernel.org/r/20161130142955.gs3...@linux.vnet.ibm.com > > [2] http://lkml.kernel.org/r/20161201124024.gb3...@linux.vnet.ibm.com > > > > mm/vmscan.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index c05f00042430..c4abf08861d2 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -2362,6 +2362,8 @@ static void shrink_node_memcg(struct pglist_data > > *pgdat, struct mem_cgroup *memc > > } > > } > > > > + cond_resched(); > > + > > I see a cond_resched_rcu_qs() as a part of linux next inside the while > (nr[..]) loop. This is a left over from Paul's initial attempt to fix this issue. I expect him to drop his patch from his tree. He has considered it experimental anyway. > Do we need this as well? Paul is working with Peter to make cond_resched general and cover RCU stalls even when cond_resched doesn't schedule because there is no runnable task. -- Michal Hocko SUSE Labs
Re: usb/gadget: GPF in usb_gadget_unregister_driver
On Sat, Dec 3, 2016 at 6:13 PM, Greg Kroah-Hartman wrote: > On Sat, Dec 03, 2016 at 05:36:35PM +0100, Andrey Konovalov wrote: >> Hi! >> >> I've got the following error report while running the syzkaller fuzzer. >> >> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2). >> >> general protection fault: [#1] SMP KASAN >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Modules linked in: >> CPU: 0 PID: 10564 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #4 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> task: 88006cd0db40 task.stack: 88006a05 >> RIP: 0010:[] [] >> __list_del_entry+0xce/0x280 lib/list_debug.c:57 >> RSP: 0018:88006a056ea8 EFLAGS: 00010246 >> RAX: dc00 RBX: 11000d40add6 RCX: 860ceac8 >> RDX: RSI: 88006cd0e340 RDI: 860cead0 >> RBP: 88006a056f38 R08: R09: >> R10: 0006 R11: R12: >> R13: R14: 860cea00 R15: 88006a056f10 >> FS: () GS:88003ec0() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 2000d000 CR3: 05c1d000 CR4: 06f0 >> Stack: >> 859785e0 41b58ab3 8593717a 8201a9d0 >> 11000d40ade0 88006cd0db40 817e5a3c 88006cd0e338 >> 0a06 11000d40ade4 88006cd0e340 >> Call Trace: >> [] list_del+0xd/0x70 lib/list_debug.c:77 >> [] usb_gadget_unregister_driver+0x120/0x240 >> drivers/usb/gadget/udc/core.c:1365 >> [] dev_release+0x80/0x160 >> drivers/usb/gadget/legacy/inode.c:1187 >> [] __fput+0x332/0x7f0 fs/file_table.c:208 >> [] fput+0x15/0x20 fs/file_table.c:244 >> [] task_work_run+0x19b/0x270 kernel/task_work.c:116 >> [< inline >] exit_task_work include/linux/task_work.h:21 >> [] do_exit+0x16aa/0x2530 kernel/exit.c:828 >> [] do_group_exit+0x149/0x420 kernel/exit.c:932 >> [] get_signal+0x76d/0x17b0 kernel/signal.c:2307 >> [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807 >> [] exit_to_usermode_loop+0x170/0x200 >> arch/x86/entry/common.c:156 >> [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 >> [] syscall_return_slowpath+0x3d3/0x420 >> arch/x86/entry/common.c:259 >> [] entry_SYSCALL_64_fastpath+0xc0/0xc2 >> Code: c5 0f 84 e2 00 00 00 48 b8 00 02 00 00 00 00 ad de 49 39 c4 0f >> 84 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> >> 3c 02 00 0f 85 35 01 00 00 4d 8b 04 24 49 39 c8 0f 85 e1 00 >> RIP [] __list_del_entry+0xce/0x280 lib/list_debug.c:57 >> RSP >> ---[ end trace 883f708e6720200f ]--- >> Kernel panic - not syncing: Fatal exception >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Kernel Offset: disabled > > Any hints as to what you were doing when this happend? I've looked at the code. As far as I can see, it's possible for usb_gadget_probe_driver() to return 0 without adding driver to gadget_driver_pending_list (in case strcmp() returns 0 and driver->match_existing_only == true). As a result dev->gadget_registered will be set to true in dev_config() and dev_release() will call usb_gadget_unregister_driver(), which in turn will try to remove driver from gadget_driver_pending_list. Does it make any sense? > > thanks, > > greg k-h
Re: [PATCH v10 02/13] drm/mediatek: add *driver_data for different hardware settings
Hi Daniel,
On Wed, 2016-11-30 at 14:42 +0800, Daniel Kurtz wrote:
> Hi YT,
>
>
> On Fri, Nov 25, 2016 at 6:34 PM, YT Shen wrote:
> >
> > There are some hardware settings changed, between MT8173 & MT2701:
> > DISP_OVL address offset changed, color format definition changed.
> > DISP_RDMA fifo size changed.
> > DISP_COLOR offset changed.
> > MIPI_TX pll setting changed.
> > And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
>
> Sorry, I have not had time to thoroughly review the new patch set, but
> one quick comment:
>
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > index 22a33ee..cfaa760 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > @@ -78,6 +78,10 @@ struct mtk_ddp_comp_funcs {
> > struct drm_crtc_state *state);
> > };
> >
> > +struct mtk_ddp_comp_driver_data {
> > + unsigned int color_offset;
> > +};
> > +
> > struct mtk_ddp_comp {
> > struct clk *clk;
> > void __iomem *regs;
> > @@ -85,6 +89,7 @@ struct mtk_ddp_comp {
> > struct device *larb_dev;
> > enum mtk_ddp_comp_id id;
> > const struct mtk_ddp_comp_funcs *funcs;
> > + const struct mtk_ddp_comp_driver_data *data;
>
> I want to avoid adding this generic pointer here to all mtk_ddp_comp,
> since this is only used by the color component.
> Instead, define color specific types:
>
> struct mtk_disp_color_data {
>unsigned int offset;
> };
>
> struct mtk_disp_color {
>struct mtk_ddp_comp ddp_comp;
>const struct mtk_disp_color_data *data;
> };
>
> Then, add another comp_type check and fetch the dev data in
> mtk_drm_probe() or maybe mtk_ddp_comp_init().
>
> -Dan
OK, we will remove the color data pointer from generic mtk_ddp_comp.
Thanks.
Regards,
yt.shen
Re: [PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
On 29/11/16 13:57, Bartosz Golaszewski wrote:
> Add the dumb-vga-dac node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 58
>
> arch/arm/boot/dts/da850.dtsi | 17
> 2 files changed, 75 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
> b/arch/arm/boot/dts/da850-lcdk.dts
> index 711b9ad..d864f11 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -50,6 +50,53 @@
> system-clock-frequency = <24576000>;
> };
> };
> +
> + vga_bridge {
> + compatible = "dumb-vga-dac";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&display_out_vga>;
> + };
> + };
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> + };
> +
> + vga {
> + compatible = "vga-connector";
> +
> + ddc-i2c-bus = <&i2c0>;
> +
> + port {
> + vga_con_in: endpoint {
> + remote-endpoint = <&vga_bridge_out>;
> + };
> + };
> + };
> };
>
> &pmx_core {
> @@ -235,3 +282,14 @@
> &memctrl {
> status = "okay";
> };
> +
> +&display {
> + status = "okay";
> +};
> +
> +&display_out {
> + display_out_vga: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&vga_bridge_in>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 4070619..5f4ba2e 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -454,6 +454,23 @@
> reg = <0x213000 0x1000>;
> interrupts = <52>;
> status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + display_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + };
> +
> + display_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + };
> + };
> };
It's a bit difficult to follow this as there's been so many patches
going around. But I take the above is the LCDC node in the base da850
dtsi file? In that case, what is the display_in supposed to present?
It's the first node in the "display chain", so it has no input.
Also, don't touch da850.dtsi here, just add the "ports" node in the
da850-lcdk.dts file.
If the da850.dtsi has not been merged yet, I'd change the name of the
lcdc node to something else than "display". It's rather vague. If it's
named "lcdc", reading da850-lcdk.dts becomes much easier, as you'll
refer to "lcdc".
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH] doc: change the way how the stable backport is requested
On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote: > From: Michal Hocko > > Currently if a patch should aim a stable tree backport one should add > > Cc: sta...@vger.kernel.org # $version > > to the s-o-b block. This has two major disadvantages a) it spams the > stable mailing list with patches which are just discussed and not merged > yet That's not a problem in that I know I like to see them to give me a "heads up" that something is coming down the pipeline soon. I don't think anyone has ever complained of this before, do you? > and b) it is easy to make a mistake and disclose a patch via > git-send-email while it is still discussed under security embargo. Having this happen only once (maybe twice) in a over a decade really isn't that bad of odds. We have loads of embargoed security patches that properly include the cc: stable tag, yet don't leak the patch to the public mailing list. So this really is a rare thing to have happen. (also when it did happen, no one except me seemed to notice it, which was pretty funny in itself...) > In fact it is not necessary to have the stable mailing list address in > the Cc until it hits the Linus tree and all we need is to have a > grepable marker for automatic identification of such a patch. Let's > use > > stable-request: $version[s] > > instead. Where $version would tell which stable trees might be > interested in the backport. This will make the process much less error > prone without any actual downsides. We still have whole subsystems that have yet to learn about how to put proper "cc: stable@..." in their patches, why do we want to change the muscle memory of those that are doing the right thing to now have to do something else? So I don't think we need this change, let's just keep things as they are. If more and more people get sloppy and mess up, we can revisit it then. thanks, greg k-h
Re: [PATCHv2] zram: restrict add/remove attributes to root only
On Sun, Dec 04, 2016 at 09:44:13PM +0900, Sergey Senozhatsky wrote:
> zram hot_add sysfs attribute is a very 'special' attribute - reading
> from it creates a new uninitialized zram device. This file, by a mistake,
> can be read by a 'normal' user at the moment, while only root must be
> able to create a new zram device, therefore hot_add attribute must have
> S_IRUSR mode, not S_IRUGO.
>
> Fixes: 6566d1a32bf72 ("zram: add dynamic device add/remove functionality")
> Reported-by: Steven Allen
> Cc: [4.2+]
> Signed-off-by: Sergey Senozhatsky
> ---
> drivers/block/zram/zram_drv.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 5163c8f..3a0576f 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -1413,9 +1413,16 @@ static ssize_t hot_remove_store(struct class *class,
> return ret ? ret : count;
> }
>
> +/*
> + * NOTE: hot_add attribute is not the usual read-only sysfs
> + * attribute. In a sence that reading from this file does alter
> + * the state of your system -- it creates a new un-initialized
> + * zram device and returns back this device's device_id (or an
> + * error code if it fails to create a new device).
> + */
> static struct class_attribute zram_control_class_attrs[] = {
> - __ATTR_RO(hot_add),
> - __ATTR_WO(hot_remove),
> + __ATTR(hot_add, 0400, hot_add_show, NULL),
> + __ATTR(hot_remove, 0200, NULL, hot_remove_store),
You can leave hot_remove as __ATTR_WO(), right? Please do so if at all
possible.
thanks,
greg k-h
Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
On Mon, Dec 05, 2016 at 08:37:05PM +0800, Herbert Xu wrote: > On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote: > > From: LABBE Corentin > > > > The Security System have a PRNG. > > This patch add support for it as an hwrng. > > > > Signed-off-by: Corentin Labbe > > Please don't add PRNGs to hwrng. If we have existing PRNGs in > there please let me know so that we can remove them. > So how to expose PRNG to user space ? or more generally how to "use" a PRNG ? I found hisi-rng, crypto4xx_ and exynos-rng which seems to be PRNG used as hwrng. Regards
Re: [PATCH 2/2] driver core: Silence device links sphinx warning
Em Mon, 5 Dec 2016 13:44:49 +0100
Lukas Wunner escreveu:
> On Mon, Dec 05, 2016 at 10:20:53AM -0200, Mauro Carvalho Chehab wrote:
> > Em Sun, 4 Dec 2016 13:10:04 +0100 Lukas Wunner escreveu:
> > > Silence this warning emitted by sphinx:
> > > include/linux/device.h:938: warning: No description found for parameter
> > > 'links'
> > >
> > > While at it, fix typos in comments of device links code.
> > >
> > > Cc: Rafael J. Wysocki
> > > Cc: Greg Kroah-Hartman
> > > Cc: Jonathan Corbet
> > > Cc: Silvio Fricke
> > > Signed-off-by: Lukas Wunner
> > > ---
> > > drivers/base/core.c| 4 ++--
> > > include/linux/device.h | 1 +
> > > 2 files changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > > index d0c9df5..8c25e68 100644
> > > --- a/drivers/base/core.c
> > > +++ b/drivers/base/core.c
> > > @@ -172,7 +172,7 @@ static int device_reorder_to_tail(struct device *dev,
> > > void *not_used)
> > > *
> > > * The supplier device is required to be registered when this function
> > > is called
> > > * and NULL will be returned if that is not the case. The consumer
> > > device need
> > > - * not be registerd, however.
> > > + * not be registered, however.
> > > */
> > > struct device_link *device_link_add(struct device *consumer,
> > > struct device *supplier, u32 flags)
> > > @@ -225,7 +225,7 @@ struct device_link *device_link_add(struct device
> > > *consumer,
> > > INIT_LIST_HEAD(&link->c_node);
> > > link->flags = flags;
> > >
> > > - /* Deterine the initial link state. */
> > > + /* Determine the initial link state. */
> > > if (flags & DL_FLAG_STATELESS) {
> > > link->status = DL_STATE_NONE;
> > > } else {
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index 3896af4..87edfdf 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -813,6 +813,7 @@ struct dev_links_info {
> > > * on. This shrinks the "Board Support Packages" (BSPs)
> > > and
> > > * minimizes board-specific #ifdefs in drivers.
> > > * @driver_data: Private pointer for driver specific info.
> > > + * @links: Links to suppliers and consumers of this device.
> > > * @power: For device power management.
> > > * See Documentation/power/admin-guide/devices.rst for
> > > details.
> > > * @pm_domain: Provide callbacks that are executed during system
> > > suspend,
> >
> > Hmm... I'm not seeing "links" at driver-core-next:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/gregkh/driver-core.git/tree/include/linux/device.h?h=driver-core-next
> >
> > On what tree did you base this patch?
>
> You're looking at the right tree, just maybe not the right line. :-)
Ah, OK! yeah, I was tricked by this:
@@ -813,6 +813,7 @@ struct dev_links_info {
Need more caffeine ;)
> It's in line 887:
>
>
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/driver-core.git/tree/include/linux/device.h?h=driver-core-next#n887
Patch looks good on my eyes.
Reviewed-by: Mauro Carvalho Chehab
--
Thanks,
Mauro
Re: [PATCH v10 13/13] drm/mediatek: add support for Mediatek SoC MT2701
On Wed, 2016-11-30 at 15:03 +0100, Matthias Brugger wrote:
>
> On 25/11/16 11:34, YT Shen wrote:
>
> > static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> > + { .compatible = "mediatek,mt2701-disp-rdma",
> > + .data = &mt2701_rdma_driver_data},
> > { .compatible = "mediatek,mt8173-disp-rdma",
> > .data = &mt8173_rdma_driver_data},
> > {},
>
> [...]
>
> > static const struct of_device_id ddp_driver_dt_match[] = {
> > + { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> > { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> > {},
> > };
>
> [...]
>
> >
> > static const struct of_device_id mtk_disp_color_driver_dt_match[] = {
> > + { .compatible = "mediatek,mt2701-disp-color",
> > + .data = &mt2701_color_driver_data},
> > { .compatible = "mediatek,mt8173-disp-color",
> > .data = &mt8173_color_driver_data},
> > {},
>
> [...]
>
> > static const struct of_device_id mtk_drm_of_ids[] = {
> > + { .compatible = "mediatek,mt2701-mmsys",
> > + .data = &mt2701_mmsys_driver_data},
> > { .compatible = "mediatek,mt8173-mmsys",
> > .data = &mt8173_mmsys_driver_data},
> > { }
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index 0569f2e..f63cc91 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -1203,6 +1203,7 @@ static int mtk_dsi_remove(struct platform_device
> > *pdev)
> > }
> >
> > static const struct of_device_id mtk_dsi_of_match[] = {
> > + { .compatible = "mediatek,mt2701-dsi" },
> > { .compatible = "mediatek,mt8173-dsi" },
> > { },
> > };
>
> [...]
>
> >
> > static const struct of_device_id mtk_mipi_tx_match[] = {
> > + { .compatible = "mediatek,mt2701-mipi-tx",
> > + .data = &mt2701_mipitx_data },
> > { .compatible = "mediatek,mt8173-mipi-tx",
> > .data = &mt8173_mipitx_data },
> > {},
>
> I'm not sure if I missed some, but you should update the binding
> description for newly added bindings.
>
> Thanks a lot,
> Matthias
Oh, you are right. I thought there is already sent binding description
but actually no. I will update this part for newly added bindings.
Thanks for informing.
yt.shen
Re: [LINUX RFC v4 3/4] mtd: spi-nor: add stripe support
Hi Naga,
Le 05/12/2016 à 08:02, Naga Sureshkumar Relli a écrit :
> Hi Cyrille,
>
>>> Hi Cyrille,
>>>
I have not finished to review the whole series yet but here some
first
comments:
>>>
>>> Thanks for reviewing these patch series.
>>>
Le 27/11/2016 à 09:33, Naga Sureshkumar Relli a écrit :
> This patch adds stripe support and it is needed for GQSPI parallel
> configuration mode by:
>
> - Adding required parameters like stripe and shift to spi_nor
> structure.
> - Initializing all added parameters in spi_nor_scan()
> - Updating read_sr() and read_fsr() for getting status from both
> flashes
> - Increasing page_size, sector_size, erase_size and toatal flash
> size as and when required.
> - Dividing address by 2
> - Updating spi->master->flags for qspi driver to change CS
>
> Signed-off-by: Naga Sureshkumar Relli
> ---
> Changes for v4:
> - rename isparallel to stripe
> Changes for v3:
> - No change
> Changes for v2:
> - Splitted to separate MTD layer changes from SPI core changes
> ---
> drivers/mtd/spi-nor/spi-nor.c | 130
--
> include/linux/mtd/spi-nor.h | 2 +
> 2 files changed, 103 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/spi-nor.c
> b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..4252239 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> /* Define max times to check status register before we give up. */
>
> @@ -89,15 +90,24 @@ static const struct flash_info
> *spi_nor_match_id(const char *name); static int read_sr(struct
> spi_nor *nor) {
> int ret;
> - u8 val;
> + u8 val[2];
>
> - ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val, 1);
> - if (ret < 0) {
> - pr_err("error %d reading SR\n", (int) ret);
> - return ret;
> + if (nor->stripe) {
> + ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 2);
> + if (ret < 0) {
> + pr_err("error %d reading SR\n", (int) ret);
> + return ret;
> + }
> + val[0] |= val[1];
Why '|' rather than '&' ?
I guess because of the 'Write In Progress/Busy' bit: when called by
spi_nor_sr_ready(), you want to be sure that this 'BUSY' bit is
cleared on both memories.
But what about when the Status Register is read for purpose other
than checking the state of the 'BUSY' bit?
>>> Yes you are correct, I will change this.
>>>
What about SPI controllers supporting more than 2 memories in parallel?
This solution might fit the ZynqMP controller but doesn't look so generic.
> + } else {
> + ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 1);
> + if (ret < 0) {
> + pr_err("error %d reading SR\n", (int) ret);
> + return ret;
> + }
> }
>
> - return val;
> + return val[0];
> }
>
> /*
> @@ -108,15 +118,24 @@ static int read_sr(struct spi_nor *nor)
> static int read_fsr(struct spi_nor *nor) {
> int ret;
> - u8 val;
> + u8 val[2];
>
> - ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
> - if (ret < 0) {
> - pr_err("error %d reading FSR\n", ret);
> - return ret;
> + if (nor->stripe) {
> + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 2);
> + if (ret < 0) {
> + pr_err("error %d reading FSR\n", ret);
> + return ret;
> + }
> + val[0] &= val[1];
Same comment here: why '&' rather than '|'?
Surely because of the the 'READY' bit which should be set for both
>> memories.
>>> I will update this also.
> + } else {
> + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 1);
> + if (ret < 0) {
> + pr_err("error %d reading FSR\n", ret);
> + return ret;
> + }
> }
>
> - return val;
> + return val[0];
> }
>
> /*
> @@ -290,9 +309,16 @@ static int spi_nor_wait_till_ready(struct
> spi_nor
*nor)
> */
> static int erase_chip(struct spi_nor *nor) {
> + u32 ret;
> +
> dev_dbg(nor->dev, " %lldKiB\n", (long long)(nor->mtd.size >> 10));
>
> - return nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
> + ret = nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
> + if (ret)
> + return ret;
> +
> + return ret;
> +
if (ret)
return ret;
else
return ret;
This chunk should be removed, it doesn't ease the patch review ;)
>>> O
Re: [RFC PATCH] doc: change the way how the stable backport is requested
On Mon 05-12-16 13:52:36, Greg KH wrote: > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > Currently if a patch should aim a stable tree backport one should add > > > > Cc: sta...@vger.kernel.org # $version > > > > to the s-o-b block. This has two major disadvantages a) it spams the > > stable mailing list with patches which are just discussed and not merged > > yet > > That's not a problem in that I know I like to see them to give me a > "heads up" that something is coming down the pipeline soon. Are you really tracking all those discussion to catch resulting patches in the Linus' tree? I simply fail to see a point having N versions of the patch on the stable mailing list before it gets picked up from the _Linus'_ anyayw. > I don't think anyone has ever complained of this before, do you? This is the reason I have stopped following the stable mailing list. The noise level is just too high. > > and b) it is easy to make a mistake and disclose a patch via > > git-send-email while it is still discussed under security embargo. > > Having this happen only once (maybe twice) in a over a decade really > isn't that bad of odds. We have loads of embargoed security patches > that properly include the cc: stable tag, yet don't leak the patch to > the public mailing list. So this really is a rare thing to have happen. Rare, still annoying and unnecessarily error prone. Btw. even git send-email will not cope with Cc: stable # version properly... Here is what I get when not using --suppress-cc=body on this particular patch :From: Michal Hocko :To: LKML :Cc: Michal Hocko , :sta...@vger.kernel.org, :#, :$version :Subject: [RFC PATCH] doc: change the way how the stable backport is requested > (also when it did happen, no one except me seemed to notice it, which > was pretty funny in itself...) You can be pretty sure people have noticed even when not pointing that out as a response to the particular email... > > In fact it is not necessary to have the stable mailing list address in > > the Cc until it hits the Linus tree and all we need is to have a > > grepable marker for automatic identification of such a patch. Let's > > use > > > > stable-request: $version[s] > > > > instead. Where $version would tell which stable trees might be > > interested in the backport. This will make the process much less error > > prone without any actual downsides. > > We still have whole subsystems that have yet to learn about how to put > proper "cc: stable@..." in their patches, why do we want to change the > muscle memory of those that are doing the right thing to now have to do > something else? I completely see this argument. It will take some time for people to adapt any changes in the workflow. No question about that. I just believe that a less error prone process would be more comfortable long term. Making stable ML being only about stable related patches and the follow up discussions sounds like an improvemnt to me as well. -- Michal Hocko SUSE Labs
[PATCH] SPCR: check bit width for the 16550 UART
Check the 'Register Bit Width' field of the ACPI Generic Address Structure that specifies the address of the UART registers to decide if the driver should use "mmio32" access instead of "mmio". If the driver is other than 16550 the access with is defined by the Interface Type field of the SPCR table. For discussion: https://lkml.kernel.org/r/7fa523de-3fbb-1566-f521-927143f73...@redhat.com Signed-off-by: Aleksey Makarov Signed-off-by: Graeme Gregory Reported-by: Heyi Guo --- drivers/acpi/spcr.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c index e8d7bc7..6c6710b 100644 --- a/drivers/acpi/spcr.c +++ b/drivers/acpi/spcr.c @@ -70,6 +70,10 @@ int __init parse_spcr(bool earlycon) break; case ACPI_DBG2_16550_COMPATIBLE: case ACPI_DBG2_16550_SUBSET: + if (table->serial_port.space_id == + ACPI_ADR_SPACE_SYSTEM_MEMORY && + table->serial_port.bit_width == 32) + iotype = "mmio32"; uart = "uart"; break; default: -- 2.10.2
Re: [PATCH 1/2] Documentation/core-api/device_link: Add initial documentation
On Mon, 5 Dec 2016 10:07:39 -0200 Mauro Carvalho Chehab wrote: > > +Usage > > += > > You should be using, instead: > > Usage > - > > (and the same '-' symbol for all sections of this chapter) > > The way you did, in thesis, ReST should be putting all tags at the > same level as the first one, as they're all using '='. Actually, he did exactly what the documentation guide says to do. Since it only has the markers below the heading, it will still be at a lower level than the top heading, which has markers both above and below. jon
Re: [PATCH 0/2] Device links documentation
[Trimming the CC list a bit; claws-mail chokes on the full thing for some reason] On Sun, 4 Dec 2016 13:10:04 +0100 Lukas Wunner wrote: > @Jonathan Corbet: Is core-api the right place to put this? An > alternative would be Documentation/driver-api, but unlike core-api > it contains less prose text but mostly just bare API docs gleaned > from kernel-doc. The amount of prose isn't really the determining factor here... To me, this is very much driver-oriented documentation, so I would rather see it going into the driver-api sub-book. Thanks for putting it together, jon
usb/gadget: use-after-free in gadgetfs_setup
Hi! I've got the following error report while running the syzkaller fuzzer. On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2). BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr 88003dfe5bf2 Read of size 2 by task syz-executor0/22994 CPU: 3 PID: 22994 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 88006df06a18 81f96aba e0528500 11000dbe0cd6 ed000dbe0cce 88006df068f0 41b58ab3 8598b4c8 81f96828 11000dbe0ccd 88006df06708 88006df06748 Call Trace: [ 201.343209] [< inline >] __dump_stack lib/dump_stack.c:15 [ 201.343209] [] dump_stack+0x292/0x398 lib/dump_stack.c:51 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159 [< inline >] print_address_description mm/kasan/report.c:197 [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286 [< inline >] kasan_report mm/kasan/report.c:306 [] __asan_report_load_n_noabort+0x3a/0x40 mm/kasan/report.c:337 [< inline >] config_buf drivers/usb/gadget/legacy/inode.c:1298 [] gadgetfs_setup+0x208a/0x20e0 drivers/usb/gadget/legacy/inode.c:1368 [] dummy_timer+0x11f0/0x36d0 drivers/usb/gadget/udc/dummy_hcd.c:1858 [] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308 [< inline >] expire_timers kernel/time/timer.c:1348 [] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641 [] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654 [] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284 [< inline >] invoke_softirq kernel/softirq.c:364 [] irq_exit+0x19e/0x1d0 kernel/softirq.c:405 [< inline >] exiting_irq arch/x86/include/asm/apic.h:659 [] smp_apic_timer_interrupt+0x7b/0xa0 arch/x86/kernel/apic/apic.c:960 [] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:489 [ 201.343209] [] ? _raw_spin_unlock_irqrestore+0x119/0x1a0 [] try_to_wake_up+0x174/0x1160 kernel/sched/core.c:2099 [< inline >] wake_up_process kernel/sched/core.c:2165 [] wake_up_q+0x8a/0xe0 kernel/sched/core.c:469 [] futex_wake+0x5be/0x6c0 kernel/futex.c:1453 [] do_futex+0x11bd/0x1f00 kernel/futex.c:3219 [< inline >] SYSC_futex kernel/futex.c:3275 [] SyS_futex+0x2fc/0x400 kernel/futex.c:3243 [] entry_SYSCALL_64_fastpath+0x1f/0xc2 Object at 88003dfe5bf0, in cache kmalloc-32 size: 32 Allocated: PID = 21625 [ 201.343209] [] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 [ 201.343209] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495 [ 201.343209] [< inline >] set_track mm/kasan/kasan.c:507 [ 201.343209] [] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:598 [ 201.343209] [] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:537 [ 201.343209] [< inline >] slab_post_alloc_hook mm/slab.h:417 [ 201.343209] [< inline >] slab_alloc_node mm/slub.c:2708 [ 201.343209] [< inline >] slab_alloc mm/slub.c:2716 [ 201.343209] [] __kmalloc_track_caller+0x195/0x290 mm/slub.c:4240 [ 201.343209] [] memdup_user+0x2c/0xa0 mm/util.c:137 [ 201.343209] [] dev_config+0x2eb/0x1190 drivers/usb/gadget/legacy/inode.c:1778 [ 201.343209] [] __vfs_write+0x5d5/0x760 fs/read_write.c:510 [ 201.343209] [] vfs_write+0x170/0x4e0 fs/read_write.c:560 [ 201.343209] [< inline >] SYSC_write fs/read_write.c:607 [ 201.343209] [] SyS_write+0xfb/0x230 fs/read_write.c:599 [ 201.343209] [] entry_SYSCALL_64_fastpath+0x1f/0xc2 Freed: PID = 21625 [ 201.343209] [] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 [ 201.343209] [] save_stack+0x43/0xd0 mm/kasan/kasan.c:495 [ 201.343209] [< inline >] set_track mm/kasan/kasan.c:507 [ 201.343209] [] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:571 [ 201.343209] [< inline >] slab_free_hook mm/slub.c:1352 [ 201.343209] [< inline >] slab_free_freelist_hook mm/slub.c:1374 [ 201.343209] [< inline >] slab_free mm/slub.c:2951 [ 201.343209] [] kfree+0xe7/0x2b0 mm/slub.c:3871 [ 201.343209] [] dev_config+0xc0b/0x1190 drivers/usb/gadget/legacy/inode.c:1848 [ 201.343209] [] __vfs_write+0x5d5/0x760 fs/read_write.c:510 [ 201.343209] [] vfs_write+0x170/0x4e0 fs/read_write.c:560 [ 201.343209] [< inline >] SYSC_write fs/read_write.c:607 [ 201.343209] [] SyS_write+0xfb/0x230 fs/read_write.c:599 [ 201.343209] [] entry_SYSCALL_64_fastpath+0x1f/0xc2 Memory state around the buggy address: 88003dfe5a80: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc 88003dfe5b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >88003dfe5b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb ^ 88003dfe5c00: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc 88003dfe5c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ==
[PATCH 1/4] rtc: mcp795: fix invalid month setting.
The 10 month register was always set to value 0 in the RTC hardware.
Due to the bug month November or December became February.
---
drivers/rtc/rtc-mcp795.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-mcp795.c b/drivers/rtc/rtc-mcp795.c
index 4021fd0..266328b 100644
--- a/drivers/rtc/rtc-mcp795.c
+++ b/drivers/rtc/rtc-mcp795.c
@@ -29,7 +29,7 @@
#define MCP795_EEWREN 0x06
#define MCP795_SRREAD 0x05
#define MCP795_SRWRITE 0x01
-#define MCP795_READ0x13
+#define MCP795_READ0x13
#define MCP795_WRITE 0x12
#define MCP795_UNLOCK 0x14
#define MCP795_IDWRITE 0x32
@@ -39,6 +39,7 @@
#define MCP795_ST_BIT 0x80
#define MCP795_24_BIT 0x40
+#define MCP795_LP_BIT 0x20
static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 count)
{
@@ -108,7 +109,8 @@ static int mcp795_set_time(struct device *dev, struct
rtc_time *tim)
data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | (tim->tm_min %
10);
data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
- data[5] = (data[5] & 0x10) | (tim->tm_mon / 10) | (tim->tm_mon % 10);
+ data[5] = (data[5] & MCP795_LP_BIT) |
+ ((tim->tm_mon / 10) << 4) | (tim->tm_mon % 10);
if (tim->tm_year > 100)
tim->tm_year -= 100;
@@ -137,11 +139,11 @@ static int mcp795_read_time(struct device *dev, struct
rtc_time *tim)
if (ret)
return ret;
- tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] &
0x0f);
- tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] &
0x0f);
+ tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 0x0f);
+ tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 0x0f);
tim->tm_hour= ((data[2] & 0x30) >> 4) * 10 + (data[2] & 0x0f);
tim->tm_mday= ((data[4] & 0x30) >> 4) * 10 + (data[4] & 0x0f);
- tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] &
0x0f);
+ tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 0x0f);
tim->tm_year= ((data[6] & 0xf0) >> 4) * 10 + (data[6] & 0x0f) +
100; /* Assume we are in 20xx */
dev_dbg(dev, "Read from mcp795: %04d-%02d-%02d %02d:%02d:%02d\n",
--
2.7.4
[PATCH 0/4] Provides bug fixes for rtc-mcp795.c
This patchset provides 3 bug fixes (patch 1, 2 and 3) and one improvement (patch 4) in the file driver/rtc/rtc-mcp795.c. Please review the changes and consider to apply them to the main kernel tree. Emil Bartczak (4): rtc: mcp795: fix invalid month setting. rtc: mcp795: fix time range difference between linux and RTC chip rtc: mcp795: fix month write resetting date to 1. rtc: mcp795: use bcd2bin/bin2bcd. drivers/rtc/rtc-mcp795.c | 125 +++ 1 file changed, 94 insertions(+), 31 deletions(-) -- 2.7.4
[PATCH 4/4] rtc: mcp795: use bcd2bin/bin2bcd.
Change rtc-mcp795.c to use the bcd2bin/bin2bcd functions.
---
drivers/rtc/rtc-mcp795.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/rtc/rtc-mcp795.c b/drivers/rtc/rtc-mcp795.c
index c9ad46c..1d823f9 100644
--- a/drivers/rtc/rtc-mcp795.c
+++ b/drivers/rtc/rtc-mcp795.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/* MCP795 Instructions, see datasheet table 3-1 */
#define MCP795_EEREAD 0x03
@@ -137,7 +138,6 @@ static int mcp795_start_oscillator(struct device *dev)
static int mcp795_set_time(struct device *dev, struct rtc_time *tim)
{
- int month;
int ret;
u8 data[7];
@@ -152,10 +152,10 @@ static int mcp795_set_time(struct device *dev, struct
rtc_time *tim)
if (ret)
return ret;
- data[0] = (data[0] & 0x80) | ((tim->tm_sec / 10) << 4) | (tim->tm_sec %
10);
- data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | (tim->tm_min %
10);
- data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
- data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
+ data[0] = (data[0] & 0x80) | bin2bcd(tim->tm_sec);
+ data[1] = (data[1] & 0x80) | bin2bcd(tim->tm_min);
+ data[2] = bin2bcd(tim->tm_hour);
+ data[4] = bin2bcd(tim->tm_mday);
/* Always write the date and month using a separate Write command.
* This is a workaround for a know silicon issue that some combinations
@@ -166,14 +166,12 @@ static int mcp795_set_time(struct device *dev, struct
rtc_time *tim)
if (ret)
return ret;
- month = tim->tm_mon + 1;
- data[5] = (data[5] & MCP795_LP_BIT) |
- ((month / 10) << 4) | (month % 10);
+ data[5] = (data[5] & MCP795_LP_BIT) | bin2bcd(tim->tm_mon + 1);
if (tim->tm_year > 100)
tim->tm_year -= 100;
- data[6] = ((tim->tm_year / 10) << 4) | (tim->tm_year % 10);
+ data[6] = bin2bcd(tim->tm_year);
ret = mcp795_rtcc_write(dev, MCP795_REG_MONTH, &data[5], 2);
@@ -202,12 +200,12 @@ static int mcp795_read_time(struct device *dev, struct
rtc_time *tim)
if (ret)
return ret;
- tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 0x0f);
- tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 0x0f);
- tim->tm_hour= ((data[2] & 0x30) >> 4) * 10 + (data[2] & 0x0f);
- tim->tm_mday= ((data[4] & 0x30) >> 4) * 10 + (data[4] & 0x0f);
- tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 0x0f) - 1;
- tim->tm_year= ((data[6] & 0xf0) >> 4) * 10 + (data[6] & 0x0f) +
100; /* Assume we are in 20xx */
+ tim->tm_sec = bcd2bin(data[0] & 0x7F);
+ tim->tm_min = bcd2bin(data[1] & 0x7F);
+ tim->tm_hour= bcd2bin(data[2] & 0x3F);
+ tim->tm_mday= bcd2bin(data[4] & 0x3F);
+ tim->tm_mon = bcd2bin(data[5] & 0x1F) - 1;
+ tim->tm_year= bcd2bin(data[6]) + 100; /* Assume we are in 20xx */
dev_dbg(dev, "Read from mcp795: %04d-%02d-%02d %02d:%02d:%02d\n",
tim->tm_year + 1900, tim->tm_mon, tim->tm_mday,
--
2.7.4
[PATCH 2/4] rtc: mcp795: fix time range difference between linux and RTC chip
In linux rtc_time struct, tm_mon range is 0~11, while in RTC HW REG,
month range is 1~12. This patch adjusts difference of them.
---
drivers/rtc/rtc-mcp795.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-mcp795.c b/drivers/rtc/rtc-mcp795.c
index 266328b..d15072c 100644
--- a/drivers/rtc/rtc-mcp795.c
+++ b/drivers/rtc/rtc-mcp795.c
@@ -96,6 +96,7 @@ static int mcp795_rtcc_set_bits(struct device *dev, u8 addr,
u8 mask, u8 state)
static int mcp795_set_time(struct device *dev, struct rtc_time *tim)
{
+ int month;
int ret;
u8 data[7];
@@ -109,8 +110,9 @@ static int mcp795_set_time(struct device *dev, struct
rtc_time *tim)
data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | (tim->tm_min %
10);
data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
+ month = tim->tm_mon + 1;
data[5] = (data[5] & MCP795_LP_BIT) |
- ((tim->tm_mon / 10) << 4) | (tim->tm_mon % 10);
+ ((month / 10) << 4) | (month % 10);
if (tim->tm_year > 100)
tim->tm_year -= 100;
@@ -143,7 +145,7 @@ static int mcp795_read_time(struct device *dev, struct
rtc_time *tim)
tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 0x0f);
tim->tm_hour= ((data[2] & 0x30) >> 4) * 10 + (data[2] & 0x0f);
tim->tm_mday= ((data[4] & 0x30) >> 4) * 10 + (data[4] & 0x0f);
- tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 0x0f);
+ tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 0x0f) - 1;
tim->tm_year= ((data[6] & 0xf0) >> 4) * 10 + (data[6] & 0x0f) +
100; /* Assume we are in 20xx */
dev_dbg(dev, "Read from mcp795: %04d-%02d-%02d %02d:%02d:%02d\n",
--
2.7.4
[PATCH 3/4] rtc: mcp795: fix month write resetting date to 1.
According to Microchip errata some combinations of date and month
values may result in the date being reset to 1, even if the date
is also written with the month (for example 31-07 or 31-08).
As a workaround avoid writing date and month values within the same
Write command. Instead, terminate the Write command after loading
the date and begin a new command to write the month. In addition,
disable the oscillator before loading the new values. This is done
by ensuring both the ST and EXTOSC bits are cleared and waiting for
the OSCON bit to clear.
---
drivers/rtc/rtc-mcp795.c | 103 +--
1 file changed, 82 insertions(+), 21 deletions(-)
diff --git a/drivers/rtc/rtc-mcp795.c b/drivers/rtc/rtc-mcp795.c
index d15072c..c9ad46c 100644
--- a/drivers/rtc/rtc-mcp795.c
+++ b/drivers/rtc/rtc-mcp795.c
@@ -21,25 +21,34 @@
#include
#include
#include
+#include
/* MCP795 Instructions, see datasheet table 3-1 */
-#define MCP795_EEREAD 0x03
-#define MCP795_EEWRITE 0x02
-#define MCP795_EEWRDI 0x04
-#define MCP795_EEWREN 0x06
-#define MCP795_SRREAD 0x05
-#define MCP795_SRWRITE 0x01
-#define MCP795_READ0x13
-#define MCP795_WRITE 0x12
-#define MCP795_UNLOCK 0x14
-#define MCP795_IDWRITE 0x32
-#define MCP795_IDREAD 0x33
-#define MCP795_CLRWDT 0x44
-#define MCP795_CLRRAM 0x54
-
-#define MCP795_ST_BIT 0x80
-#define MCP795_24_BIT 0x40
-#define MCP795_LP_BIT 0x20
+#define MCP795_EEREAD 0x03
+#define MCP795_EEWRITE 0x02
+#define MCP795_EEWRDI 0x04
+#define MCP795_EEWREN 0x06
+#define MCP795_SRREAD 0x05
+#define MCP795_SRWRITE 0x01
+#define MCP795_READ0x13
+#define MCP795_WRITE 0x12
+#define MCP795_UNLOCK 0x14
+#define MCP795_IDWRITE 0x32
+#define MCP795_IDREAD 0x33
+#define MCP795_CLRWDT 0x44
+#define MCP795_CLRRAM 0x54
+
+/* MCP795 RTCC registers, see datasheet table 4-1 */
+#define MCP795_REG_SECONDS 0x01
+#define MCP795_REG_DAY 0x04
+#define MCP795_REG_MONTH 0x06
+#define MCP795_REG_CONTROL 0x08
+
+#define MCP795_ST_BIT 0x80
+#define MCP795_24_BIT 0x40
+#define MCP795_LP_BIT 0x20
+#define MCP795_EXTOSC_BIT 0x08
+#define MCP795_OSCON_BIT 0x20
static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 count)
{
@@ -94,14 +103,51 @@ static int mcp795_rtcc_set_bits(struct device *dev, u8
addr, u8 mask, u8 state)
return ret;
}
+static int mcp795_stop_oscillator(struct device *dev)
+{
+ int retries = 5;
+ int ret;
+ u8 data;
+
+ ret = mcp795_rtcc_set_bits(dev, MCP795_REG_SECONDS, MCP795_ST_BIT, 0);
+ if (ret)
+ return ret;
+ ret = mcp795_rtcc_set_bits(dev, MCP795_REG_CONTROL, MCP795_EXTOSC_BIT,
0);
+ if (ret)
+ return ret;
+ do {
+ usleep_range(700, 800);
+ ret = mcp795_rtcc_read(dev, MCP795_REG_DAY,
+ &data, sizeof(data));
+ if (ret)
+ break;
+ if (!(data & MCP795_OSCON_BIT))
+ break;
+
+ } while (--retries);
+
+ return !retries ? -EIO : ret;
+}
+
+static int mcp795_start_oscillator(struct device *dev)
+{
+ return mcp795_rtcc_set_bits(dev, MCP795_REG_SECONDS,
+ MCP795_ST_BIT, MCP795_ST_BIT);
+}
+
static int mcp795_set_time(struct device *dev, struct rtc_time *tim)
{
int month;
int ret;
u8 data[7];
+ /* Stop RTC while updating the registers */
+ ret = mcp795_stop_oscillator(dev);
+ if (ret)
+ return ret;
+
/* Read first, so we can leave config bits untouched */
- ret = mcp795_rtcc_read(dev, 0x01, data, sizeof(data));
+ ret = mcp795_rtcc_read(dev, MCP795_REG_SECONDS, data, sizeof(data));
if (ret)
return ret;
@@ -110,6 +156,16 @@ static int mcp795_set_time(struct device *dev, struct
rtc_time *tim)
data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | (tim->tm_min %
10);
data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
+
+ /* Always write the date and month using a separate Write command.
+* This is a workaround for a know silicon issue that some combinations
+* of date and month values may result in the date being reset to 1.
+*/
+ ret = mcp795_rtcc_write(dev, MCP795_REG_SECONDS, data, 5);
+
+ if (ret)
+ return ret;
+
month = tim->tm_mon + 1;
data[5] = (data[5] & MCP795_LP_BIT) |
((month / 10) << 4) | (month % 10);
@@ -119,8 +175,13 @@ static int mcp795_set_time(struct device *dev, struct
rtc_time *tim)
data[6] = ((tim->tm_year / 10) << 4) | (tim->tm_year % 10);
- ret = mcp795_rtcc_write(d
Re: [PATCH v2] v4l: async: make v4l2 coexist with devicetree nodes in a dt overlay
Hello Javi,
On 12/05/2016 07:09 AM, Javi Merino wrote:
> In asds configured with V4L2_ASYNC_MATCH_OF, the v4l2 subdev can be
> part of a devicetree overlay, for example:
>
> &media_bridge {
> ...
> my_port: port@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
> ep: endpoint@0 {
> remote-endpoint = <&camera0>;
> };
> };
> };
>
> / {
> fragment@0 {
> target = <&i2c0>;
> __overlay__ {
> my_cam {
> compatible = "foo,bar";
> port {
> camera0: endpoint {
> remote-endpoint = <&my_port>;
> ...
> };
> };
> };
> };
> };
> };
>
> Each time the overlay is applied, its of_node pointer will be
> different. We are not interested in matching the pointer, what we
> want to match is that the path is the one we are expecting. Change to
> use of_node_cmp() so that we continue matching after the overlay has
> been removed and reapplied.
>
> Cc: Mauro Carvalho Chehab
> Cc: Javier Martinez Canillas
> Cc: Sakari Ailus
> Signed-off-by: Javi Merino
> ---
I already reviewed v1 but you didn't carry the tag. So again:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
Re: [RFC PATCH] doc: change the way how the stable backport is requested
Hi Michal, On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote: > > That's not a problem in that I know I like to see them to give me a > > "heads up" that something is coming down the pipeline soon. > > Are you really tracking all those discussion to catch resulting patches > in the Linus' tree? I simply fail to see a point having N versions of > the patch on the stable mailing list before it gets picked up from the > _Linus'_ anyayw. > > > I don't think anyone has ever complained of this before, do you? > > This is the reason I have stopped following the stable mailing list. > The noise level is just too high. I personally have mixed opinion on this. I agree that there's too much "noise" on the list, but at the same time I would probably be even more clueless about patches I receive if I didn't have this noise. As Greg says, these emails tell you something is coming. For sure I don't keep track of the discussions nor the threads but sometimes I'm interested in reading them and that makes my later job easier. So in the end, I just press ",st" in mutt and all stable mails are moved away from my mbox and archived into the stable box. My only risk at the moment is to accidently miss something that people expected me to merge by sending it to stable only, but that doesn't happen often. So I think I'm fine with not changing anything as well. cheers, Willy
Loan Offer
We can help you with a genuine loan to meet your needs. Do you need a personal or business loan without stress and quick approval? Do you need an urgent loan today? No Credit Checks * LOAN APPROVAL IN 60MINS !! * GUARANTEED SAME DAY TRANSFER !! * 100% APPROVAL RATE !! * LOW INTEREST RATE !! Contact US for more information about loan offer and we will solve your financial problem. contact us via email: quickloa...@hotmail.com
Re: [patch net v2] net: fec: fix compile with CONFIG_M5272
Hi Nikita, [auto build test ERROR on net/master] url: https://github.com/0day-ci/linux/commits/Nikita-Yushchenko/net-fec-fix-compile-with-CONFIG_M5272/20161205-181735 config: arm-multi_v5_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): drivers/net/ethernet/freescale/fec_main.c: In function 'fec_probe': >> drivers/net/ethernet/freescale/fec_main.c:3304:7: error: 'FEC_STAT_SIZE' >> undeclared (first use in this function) FEC_STAT_SIZE, num_tx_qs, num_rx_qs); ^ drivers/net/ethernet/freescale/fec_main.c:3304:7: note: each undeclared identifier is reported only once for each function it appears in vim +/FEC_STAT_SIZE +3304 drivers/net/ethernet/freescale/fec_main.c 3298 int num_rx_qs; 3299 3300 fec_enet_get_queue_num(pdev, &num_tx_qs, &num_rx_qs); 3301 3302 /* Init network device */ 3303 ndev = alloc_etherdev_mqs(sizeof(struct fec_enet_private) + > 3304FEC_STAT_SIZE, num_tx_qs, num_rx_qs); 3305 if (!ndev) 3306 return -ENOMEM; 3307 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] mmc: sdhci-of-at91: remove bogus MMC_SDHCI_IO_ACCESSORS select
On 1 December 2016 at 05:05, Masahiro Yamada wrote: > I see no override of read/write callbacks in sdhci-of-at91.c. > > Signed-off-by: Masahiro Yamada Thanks, applied for next! Kind regards Uffe > --- > > BTW, this config may not be so useful in recent multi-platforms. > Perhaps, is it better to remove this config entirely instead of > the AT91 fix only. > > > drivers/mmc/host/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index 39f6f96..8ac1640 100644 > --- a/drivers/mmc/host/Kconfig > +++ b/drivers/mmc/host/Kconfig > @@ -135,7 +135,6 @@ config MMC_SDHCI_OF_AT91 > tristate "SDHCI OF support for the Atmel SDMMC controller" > depends on MMC_SDHCI_PLTFM > depends on OF > - select MMC_SDHCI_IO_ACCESSORS > help > This selects the Atmel SDMMC driver > > -- > 2.7.4 >
[PATCH v3] Staging: wlan-ng: hfa384x_usb.c Fixed too long code line warnings.
Fixed checkpatch warning "line over 80 characters" in
wlan-ng/hfa384x_usb.c file.
Signed-off-by: Yan Laijun
---
Changes in v2:
- Remove initialization of usbin on its decarlation.
---
Changes in v3:
- Move usbin's assignment to where it's used for the first time.
---
drivers/staging/wlan-ng/hfa384x_usb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 5f11f6e..4fe037a 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -3037,7 +3037,7 @@ static void hfa384x_usbin_callback(struct urb *urb)
{
struct wlandevice *wlandev = urb->context;
struct hfa384x *hw;
- union hfa384x_usbin *usbin = (union hfa384x_usbin
*)urb->transfer_buffer;
+ union hfa384x_usbin *usbin;
struct sk_buff *skb = NULL;
int result;
int urb_status;
@@ -3139,6 +3139,7 @@ static void hfa384x_usbin_callback(struct urb *urb)
/* Note: the check of the sw_support field, the type field doesn't
* have bit 12 set like the docs suggest.
*/
+ usbin = (union hfa384x_usbin *)urb->transfer_buffer;
type = le16_to_cpu(usbin->type);
if (HFA384x_USB_ISRXFRM(type)) {
if (action == HANDLE) {
--
1.9.1
Re: [RFC PATCH] doc: change the way how the stable backport is requested
On Mon 05-12-16 14:15:57, Willy Tarreau wrote: > Hi Michal, > > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote: > > > That's not a problem in that I know I like to see them to give me a > > > "heads up" that something is coming down the pipeline soon. > > > > Are you really tracking all those discussion to catch resulting patches > > in the Linus' tree? I simply fail to see a point having N versions of > > the patch on the stable mailing list before it gets picked up from the > > _Linus'_ anyayw. > > > > > I don't think anyone has ever complained of this before, do you? > > > > This is the reason I have stopped following the stable mailing list. > > The noise level is just too high. > > I personally have mixed opinion on this. I agree that there's too much > "noise" on the list, but at the same time I would probably be even more > clueless about patches I receive if I didn't have this noise. Is this because patches that you are receiving do not have the full context? -- Michal Hocko SUSE Labs
Re: [RFC PATCH] doc: change the way how the stable backport is requested
On Mon, Dec 05, 2016 at 02:24:00PM +0100, Michal Hocko wrote: > On Mon 05-12-16 14:15:57, Willy Tarreau wrote: > > Hi Michal, > > > > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote: > > > > That's not a problem in that I know I like to see them to give me a > > > > "heads up" that something is coming down the pipeline soon. > > > > > > Are you really tracking all those discussion to catch resulting patches > > > in the Linus' tree? I simply fail to see a point having N versions of > > > the patch on the stable mailing list before it gets picked up from the > > > _Linus'_ anyayw. > > > > > > > I don't think anyone has ever complained of this before, do you? > > > > > > This is the reason I have stopped following the stable mailing list. > > > The noise level is just too high. > > > > I personally have mixed opinion on this. I agree that there's too much > > "noise" on the list, but at the same time I would probably be even more > > clueless about patches I receive if I didn't have this noise. > > Is this because patches that you are receiving do not have the full > context? No, not at all, it's because when you're only working on old kernels, you tend to cultivate a wide gap with modern features. And actually seeing some activity related to some new features prepares you to deal with them, sometimes simply by testing them on spare time. In my case t's not exclusively a matter of applying patches, it's also about using the kernels I emit (ie eating my own food). Normally lkml is made for this but it's far too much verbose, and stable provides a resonable excerpt of things I'm supposed to visit soon. Cheers, Willy
Re: usb/gadget: GPF in usb_gadget_unregister_driver
On 12/05/2016 01:50 PM, Andrey Konovalov wrote: > On Sat, Dec 3, 2016 at 6:13 PM, Greg Kroah-Hartman > wrote: >> On Sat, Dec 03, 2016 at 05:36:35PM +0100, Andrey Konovalov wrote: >>> Hi! >>> >>> I've got the following error report while running the syzkaller fuzzer. >>> >>> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2). >>> >>> general protection fault: [#1] SMP KASAN >>> Dumping ftrace buffer: >>>(ftrace buffer empty) >>> Modules linked in: >>> CPU: 0 PID: 10564 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #4 >>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >>> task: 88006cd0db40 task.stack: 88006a05 >>> RIP: 0010:[] [] >>> __list_del_entry+0xce/0x280 lib/list_debug.c:57 >>> RSP: 0018:88006a056ea8 EFLAGS: 00010246 >>> RAX: dc00 RBX: 11000d40add6 RCX: 860ceac8 >>> RDX: RSI: 88006cd0e340 RDI: 860cead0 >>> RBP: 88006a056f38 R08: R09: >>> R10: 0006 R11: R12: >>> R13: R14: 860cea00 R15: 88006a056f10 >>> FS: () GS:88003ec0() knlGS: >>> CS: 0010 DS: ES: CR0: 80050033 >>> CR2: 2000d000 CR3: 05c1d000 CR4: 06f0 >>> Stack: >>> 859785e0 41b58ab3 8593717a 8201a9d0 >>> 11000d40ade0 88006cd0db40 817e5a3c 88006cd0e338 >>> 0a06 11000d40ade4 88006cd0e340 >>> Call Trace: >>> [] list_del+0xd/0x70 lib/list_debug.c:77 >>> [] usb_gadget_unregister_driver+0x120/0x240 >>> drivers/usb/gadget/udc/core.c:1365 >>> [] dev_release+0x80/0x160 >>> drivers/usb/gadget/legacy/inode.c:1187 >>> [] __fput+0x332/0x7f0 fs/file_table.c:208 >>> [] fput+0x15/0x20 fs/file_table.c:244 >>> [] task_work_run+0x19b/0x270 kernel/task_work.c:116 >>> [< inline >] exit_task_work include/linux/task_work.h:21 >>> [] do_exit+0x16aa/0x2530 kernel/exit.c:828 >>> [] do_group_exit+0x149/0x420 kernel/exit.c:932 >>> [] get_signal+0x76d/0x17b0 kernel/signal.c:2307 >>> [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807 >>> [] exit_to_usermode_loop+0x170/0x200 >>> arch/x86/entry/common.c:156 >>> [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 >>> [] syscall_return_slowpath+0x3d3/0x420 >>> arch/x86/entry/common.c:259 >>> [] entry_SYSCALL_64_fastpath+0xc0/0xc2 >>> Code: c5 0f 84 e2 00 00 00 48 b8 00 02 00 00 00 00 ad de 49 39 c4 0f >>> 84 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> >>> 3c 02 00 0f 85 35 01 00 00 4d 8b 04 24 49 39 c8 0f 85 e1 00 >>> RIP [] __list_del_entry+0xce/0x280 lib/list_debug.c:57 >>> RSP >>> ---[ end trace 883f708e6720200f ]--- >>> Kernel panic - not syncing: Fatal exception >>> Dumping ftrace buffer: >>>(ftrace buffer empty) >>> Kernel Offset: disabled >> >> Any hints as to what you were doing when this happend? > > I've looked at the code. > > As far as I can see, it's possible for usb_gadget_probe_driver() to > return 0 without adding driver to gadget_driver_pending_list (in case > strcmp() returns 0 and driver->match_existing_only == true). > As a result dev->gadget_registered will be set to true in dev_config() > and dev_release() will call usb_gadget_unregister_driver(), which in > turn will try to remove driver from gadget_driver_pending_list. > > Does it make any sense? > Yes. We should add gadget to pending list only if suitable UDC has not been found and gadget driver is willing to wait for new UDC to appear. Otherwise we call udc_bind_to_gadget() and if this success then we should just return 0 as we took some free udc. usually you should have empty pending list;) Your description sounds really quite similar to what Felix fixed in his patch[1]. This patch fix this function in case when we found matching UDC but it is busy. Footnotes: 1 - http://marc.info/?l=linux-usb&m=148054830631070&w=2 Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics
[PATCH v2 0/4] net: hix5hd2_gmac: add tx sg feature and reset/clock control signals
The "hix5hd2" is SoC name, add the generic ethernet driver compatible string. 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. We make these signals optional to be backward compatible with the hix5hd2 SoC. Changes in v2: - Make the compatible string changes be a separate patch and the most specific string come first than the generic string as advised by Rob. - Make the MAC reset control signals and clock signals optional to be backward compatible with the hix5hd2 SoC. - Change the compatible string and give the clock a specific name in hix5hd2 dts file. Dongpo Li (4): net: hix5hd2_gmac: add generic compatible string net: hix5hd2_gmac: add tx scatter-gather feature net: hix5hd2_gmac: add reset control and clock signals ARM: dts: hix5hd2: add gmac generic compatible and clock names .../bindings/net/hisilicon-hix5hd2-gmac.txt| 27 +- arch/arm/boot/dts/hisi-x5hd2.dtsi | 6 +- drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 352 +++-- 3 files changed, 352 insertions(+), 33 deletions(-) -- 2.8.2
[PATCH v2 2/4] net: hix5hd2_gmac: add tx scatter-gather feature
"hisi-gemac-v2" adds the SG/TXCSUM/TSO/UFO features.
This patch only adds the SG(scatter-gather) driver for transmitting,
the drivers of other features will be submitted later.
Signed-off-by: Dongpo Li
---
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 198 --
1 file changed, 187 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
index 27cb2e6..18af55b 100644
--- a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -183,6 +184,8 @@
#define DESC_DATA_LEN_OFF 16
#define DESC_BUFF_LEN_OFF 0
#define DESC_DATA_MASK 0x7ff
+#define DESC_SGBIT(30)
+#define DESC_FRAGS_NUM_OFF 11
/* DMA descriptor ring helpers */
#define dma_ring_incr(n, s)(((n) + 1) & ((s) - 1))
@@ -192,6 +195,7 @@
#define HW_CAP_TSO BIT(0)
#define GEMAC_V1 0
#define GEMAC_V2 (GEMAC_V1 | HW_CAP_TSO)
+#define HAS_CAP_TSO(hw_cap)((hw_cap) & HW_CAP_TSO)
struct hix5hd2_desc {
__le32 buff_addr;
@@ -205,6 +209,27 @@ struct hix5hd2_desc_sw {
unsigned intsize;
};
+struct hix5hd2_sg_desc_ring {
+ struct sg_desc *desc;
+ dma_addr_t phys_addr;
+};
+
+struct frags_info {
+ __le32 addr;
+ __le32 size;
+};
+
+/* hardware supported max skb frags num */
+#define SG_MAX_SKB_FRAGS 17
+struct sg_desc {
+ __le32 total_len;
+ __le32 resvd0;
+ __le32 linear_addr;
+ __le32 linear_len;
+ /* reserve one more frags for memory alignment */
+ struct frags_info frags[SG_MAX_SKB_FRAGS + 1];
+};
+
#define QUEUE_NUMS 4
struct hix5hd2_priv {
struct hix5hd2_desc_sw pool[QUEUE_NUMS];
@@ -212,6 +237,7 @@ struct hix5hd2_priv {
#define rx_bq pool[1]
#define tx_bq pool[2]
#define tx_rq pool[3]
+ struct hix5hd2_sg_desc_ring tx_ring;
void __iomem *base;
void __iomem *ctrl_base;
@@ -225,6 +251,7 @@ struct hix5hd2_priv {
struct device_node *phy_node;
phy_interface_t phy_mode;
+ unsigned long hw_cap;
unsigned int speed;
unsigned int duplex;
@@ -515,6 +542,27 @@ static int hix5hd2_rx(struct net_device *dev, int limit)
return num;
}
+static void hix5hd2_clean_sg_desc(struct hix5hd2_priv *priv,
+ struct sk_buff *skb, u32 pos)
+{
+ struct sg_desc *desc;
+ dma_addr_t addr;
+ u32 len;
+ int i;
+
+ desc = priv->tx_ring.desc + pos;
+
+ addr = le32_to_cpu(desc->linear_addr);
+ len = le32_to_cpu(desc->linear_len);
+ dma_unmap_single(priv->dev, addr, len, DMA_TO_DEVICE);
+
+ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ addr = le32_to_cpu(desc->frags[i].addr);
+ len = le32_to_cpu(desc->frags[i].size);
+ dma_unmap_page(priv->dev, addr, len, DMA_TO_DEVICE);
+ }
+}
+
static void hix5hd2_xmit_reclaim(struct net_device *dev)
{
struct sk_buff *skb;
@@ -542,8 +590,15 @@ static void hix5hd2_xmit_reclaim(struct net_device *dev)
pkts_compl++;
bytes_compl += skb->len;
desc = priv->tx_rq.desc + pos;
- addr = le32_to_cpu(desc->buff_addr);
- dma_unmap_single(priv->dev, addr, skb->len, DMA_TO_DEVICE);
+
+ if (skb_shinfo(skb)->nr_frags) {
+ hix5hd2_clean_sg_desc(priv, skb, pos);
+ } else {
+ addr = le32_to_cpu(desc->buff_addr);
+ dma_unmap_single(priv->dev, addr, skb->len,
+DMA_TO_DEVICE);
+ }
+
priv->tx_skb[pos] = NULL;
dev_consume_skb_any(skb);
pos = dma_ring_incr(pos, TX_DESC_NUM);
@@ -604,12 +659,66 @@ static irqreturn_t hix5hd2_interrupt(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+static u32 hix5hd2_get_desc_cmd(struct sk_buff *skb, unsigned long hw_cap)
+{
+ u32 cmd = 0;
+
+ if (HAS_CAP_TSO(hw_cap)) {
+ if (skb_shinfo(skb)->nr_frags)
+ cmd |= DESC_SG;
+ cmd |= skb_shinfo(skb)->nr_frags << DESC_FRAGS_NUM_OFF;
+ } else {
+ cmd |= DESC_FL_FULL |
+ ((skb->len & DESC_DATA_MASK) << DESC_BUFF_LEN_OFF);
+ }
+
+ cmd |= (skb->len & DESC_DATA_MASK) << DESC_DATA_LEN_OFF;
+ cmd |= DESC_VLD_BUSY;
+
+ return cmd;
+}
+
+static int hix5hd2_fill_sg_desc(struct hix5hd2_priv *priv,
+ struct sk_buff *skb, u32 pos)
+{
+ struct sg_desc *desc;
+ dma_addr_t addr;
+ int ret;
+ int i;
+
[PATCH v2 1/4] net: hix5hd2_gmac: add generic compatible string
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.
Signed-off-by: Dongpo Li
---
.../devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt| 9 +++--
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 15 +++
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
index 75d398b..75920f0 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
@@ -1,7 +1,12 @@
Hisilicon hix5hd2 gmac controller
Required properties:
-- compatible: should be "hisilicon,hix5hd2-gmac".
+- compatible: should contain one of the following SoC strings:
+ * "hisilicon,hix5hd2-gemac"
+ * "hisilicon,hi3798cv200-gemac"
+ and one of the following version string:
+ * "hisilicon,hisi-gemac-v1"
+ * "hisilicon,hisi-gemac-v2"
- reg: specifies base physical address(s) and size of the device registers.
The first region is the MAC register base and size.
The second region is external interface control register.
@@ -20,7 +25,7 @@ Required properties:
Example:
gmac0: ethernet@f984 {
- compatible = "hisilicon,hix5hd2-gmac";
+ compatible = "hisilicon,hix5hd2-gemac",
"hisilicon,hisi-gemac-v1";
reg = <0xf984 0x1000>,<0xf984300c 0x4>;
interrupts = <0 71 4>;
#address-cells = <1>;
diff --git a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
index e69a6be..27cb2e6 100644
--- a/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hix5hd2_gmac.c
@@ -189,6 +189,10 @@
#define dma_cnt(n) ((n) >> 5)
#define dma_byte(n)((n) << 5)
+#define HW_CAP_TSO BIT(0)
+#define GEMAC_V1 0
+#define GEMAC_V2 (GEMAC_V1 | HW_CAP_TSO)
+
struct hix5hd2_desc {
__le32 buff_addr;
__le32 cmd;
@@ -1021,7 +1025,10 @@ static int hix5hd2_dev_remove(struct platform_device
*pdev)
}
static const struct of_device_id hix5hd2_of_match[] = {
- {.compatible = "hisilicon,hix5hd2-gmac",},
+ { .compatible = "hisilicon,hisi-gemac-v1", .data = (void *)GEMAC_V1 },
+ { .compatible = "hisilicon,hisi-gemac-v2", .data = (void *)GEMAC_V2 },
+ { .compatible = "hisilicon,hix5hd2-gemac", .data = (void *)GEMAC_V1 },
+ { .compatible = "hisilicon,hi3798cv200-gemac", .data = (void *)GEMAC_V2
},
{},
};
@@ -1029,7 +1036,7 @@ MODULE_DEVICE_TABLE(of, hix5hd2_of_match);
static struct platform_driver hix5hd2_dev_driver = {
.driver = {
- .name = "hix5hd2-gmac",
+ .name = "hisi-gemac",
.of_match_table = hix5hd2_of_match,
},
.probe = hix5hd2_dev_probe,
@@ -1038,6 +1045,6 @@ static struct platform_driver hix5hd2_dev_driver = {
module_platform_driver(hix5hd2_dev_driver);
-MODULE_DESCRIPTION("HISILICON HIX5HD2 Ethernet driver");
+MODULE_DESCRIPTION("HISILICON Gigabit Ethernet MAC driver");
MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:hix5hd2-gmac");
+MODULE_ALIAS("platform:hisi-gemac");
--
2.8.2
[PATCH] bitops: add equivalent of BIT(x) for bitfields
Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with continuous bitfields, just as BIT(x) does for single bits. SETBITFIELD_ULL(msb, lsb, value) macro is also added. Signed-off-by: Sebastian Frias --- Code protected with "#ifdef __KERNEL__" just as the BIT(x) macros. I would have preferred another name, like BITS(x) but it is already used. Suggestions for other names welcome. --- include/linux/bitops.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/include/linux/bitops.h b/include/linux/bitops.h index a83c822..4659237 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -24,6 +24,20 @@ #define GENMASK_ULL(h, l) \ (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h +#ifdef __KERNEL__ +/* + * Equivalent of BIT(x) but for contiguous bitfields + * SETBITFIELD(1, 0,0xff) = 0x0003 + * SETBITFIELD(3, 0,0xff) = 0x000f + * SETBITFIELD(15,8,0xff) = 0xff00 + * SETBITFIELD(6, 6, 1) = 0x0040 == BIT(6) + */ +#define SETBITFIELD(msb, lsb, val) \ + (((val) << (lsb)) & (GENMASK((msb), (lsb +#define SETBITFIELD_ULL(msb, lsb, val) \ + (((val) << (lsb)) & (GENMASK_ULL((msb), (lsb +#endif + extern unsigned int __sw_hweight8(unsigned int w); extern unsigned int __sw_hweight16(unsigned int w); extern unsigned int __sw_hweight32(unsigned int w); -- 1.8.3.1
[PATCH v2 3/4] net: hix5hd2_gmac: add reset control and clock signals
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 "mac_core_rst" and "mac_ifc_rst" are both optional to be
backward compatible with the hix5hd2 SoC.
The "phy_rst" represents "phy reset signal", it does a hardware reset
on the PHY chip. This reset signal is optional 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.
The MAC interface clock is optional to be backward compatible with
the hix5hd2 SoC.
Signed-off-by: Dongpo Li
---
.../bindings/net/hisilicon-hix5hd2-gmac.txt| 20 ++-
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 139 +++--
2 files changed, 144 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
index 75920f0..063c02d 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"(required) and
"mac_ifc"(optional).
+- resets: should contain the phandle to the MAC core reset signal(optional),
+ the MAC interface reset signal(optional)
+ and the PHY reset signal(optional).
+- reset-names: contain the reset signal name "mac_core"(optional),
+ "mac_ifc"(optional) 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]
@@ -25,15 +35,19 @@ Required properties:
Example:
gmac0: ethernet@f984 {
- compatible = "hisilicon,hix5hd2-gemac",
"hisilicon,hisi-gemac-v1";
+ compatible = "hisilicon,hi3798cv200-gemac",
"hisilicon,hisi-gemac-v2";
reg = <0xf984 0x1000>,<0xf984300c 0x4>;
interrupts = <0 71 4>;
#address-cells = <1>;
#size-cells = <0>;
- phy-mode = "mii";
+ phy-mode = "rgmii";
phy-handle = <&phy2>;
mac-address = [00 00 00 00 00 00];
- clocks = <&clock HIX5HD2_MAC0_CLK>;
+ clocks = <&crg HISTB_ETH0_MAC_CLK>, <&crg HISTB_ETH0_MACIF_CLK>;
+ clock-names = "mac_core", "mac_ifc";
+ resets = <&crg 0xcc 8>, <&crg 0xcc 10>, <&crg 0xcc 12>;
+ 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 18af55b..ee7e9ce 100644
--- a
Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group
On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote: > > Hi Matt, > > Thanks for the results. > > During the review, it has been pointed out by Morten that the test condition > (100*this_avg_load < imbalance_scale*min_avg_load) makes more sense than > (100*min_avg_load > imbalance_scale*this_avg_load). But i see lower > performances with this change. Coud you run tests with the change below on > top of the patchset ? > > --- > kernel/sched/fair.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index e8d1ae7..0129fbb 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -5514,7 +5514,7 @@ find_idlest_group(struct sched_domain *sd, struct > task_struct *p, > if (!idlest || > (min_runnable_load > (this_runnable_load + imbalance)) || > ((this_runnable_load < (min_runnable_load + imbalance)) && > - (100*min_avg_load > imbalance_scale*this_avg_load))) > + (100*this_avg_load < imbalance_scale*min_avg_load))) > return NULL; > return idlest; > } Queued for testing.
Re: [PATCH 1/2] Documentation/core-api/device_link: Add initial documentation
Em Mon, 5 Dec 2016 06:05:07 -0700 Jonathan Corbet escreveu: > On Mon, 5 Dec 2016 10:07:39 -0200 > Mauro Carvalho Chehab wrote: > > > > +Usage > > > += > > > > You should be using, instead: > > > > Usage > > - > > > > (and the same '-' symbol for all sections of this chapter) > > > > The way you did, in thesis, ReST should be putting all tags at the > > same level as the first one, as they're all using '='. > > Actually, he did exactly what the documentation guide says to do. Ah, OK! I guess I misread that section of the documentation. > Since > it only has the markers below the heading, it will still be at a lower > level than the top heading, which has markers both above and below. Yes, I noticed that it is on a lower level than the initial one with markers above and below. Lukas, Documentation seems OK, from ReST PoV. Didn't read the documents and the C code to be sure that they match the implementation. Reviewed-by: Mauro Carvalho Chehab -- Thanks, Mauro
RE: [PATCH v6 1/2] mtd: arasan: Add device tree binding documentation
Hi Marek,
Thanks for the review.
> -Original Message-
> From: Marek Vasut [mailto:marek.va...@gmail.com]
> Sent: Monday, December 05, 2016 9:56 AM
> To: Punnaiah Choudary Kalluri ;
> dw...@infradead.org; computersforpe...@gmail.com;
> boris.brezil...@free-electrons.com; rich...@nod.at;
> cyrille.pitc...@atmel.com; robh...@kernel.org; mark.rutl...@arm.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> devicet...@vger.kernel.org; Michal Simek ;
> kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah
> Choudary Kalluri
> Subject: Re: [PATCH v6 1/2] mtd: arasan: Add device tree binding
> documentation
>
> On 12/05/2016 05:11 AM, Punnaiah Choudary Kalluri wrote:
> > This patch adds the dts binding document for arasan nand flash
> > controller.
> >
> > Signed-off-by: Punnaiah Choudary Kalluri
> > Acked-by: Rob Herring
> > ---
> > changes in v6:
> > - Removed num-cs property
> > - Separated nandchip from nand controller
> > changes in v5:
> > - None
> > Changes in v4:
> > - Added num-cs property
> > - Added clock support
> > Changes in v3:
> > - None
> > Changes in v2:
> > - None
> > ---
> > .../devicetree/bindings/mtd/arasan_nfc.txt | 38
> ++
> > 1 file changed, 38 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > new file mode 100644
> > index 000..dcbe7ad
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > @@ -0,0 +1,38 @@
> > +Arasan Nand Flash Controller with ONFI 3.1 support
>
> Arasan NAND Flash ...
>
> > +Required properties:
> > +- compatible: Should be "arasan,nfc-v3p10"
>
> This v3p10 looks like version 3 patchlevel 10, but shouldn't we have
> some fallback option which doesn't encode IP version in the compat
> string ?
>
This is a third-party IP and v3p10 is the version that we are using in our SOC.
Also this IP doesn’t have the IP version information in the register space to
read dynamically and having generic compatible name. So, any new versions
can be added through of_match_table with config data inside the driver.
> Also, shouldn't quirks be handled by DT props instead of effectively
> encoding them into the compatible string ?
>
I feel the above mentioned method will be more appropriate rather than defining
the quirks through DT properties.
I will fix all other comments
Regards,
Punnaiah
> > +- reg: Memory map for module access
> > +- interrupt-parent: Interrupt controller the interrupt is routed through
> > +- interrupts: Should contain the interrupt for the device
> > +- clock-name: List of input clocks - "clk_sys", "clk_flash"
> > + (See clock bindings for details)
> > +- clocks: Clock phandles (see clock bindings for details)
> > +
> > +Optional properties:
> > +- arasan,has-mdma: Enables Dma support
>
> 'Enables DMA support' , with DMA in caps.
>
> > +for nand partition information please refer the below file
>
> For NAND ...
>
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > + nand0: nand@ff10 {
> > + compatible = "arasan,nfc-v3p10"
> > + reg = <0x0 0xff10 0x1000>;
> > + clock-name = "clk_sys", "clk_flash"
> > + clocks = <&misc_clk &misc_clk>;
> > + interrupt-parent = <&gic>;
> > + interrupts = <0 14 4>;
> > + arasan,has-mdma;
> > + #address-cells = <1>;
> > + #size-cells = <0>
> > +
> > + nand@0 {
> > + reg = <0>
> > + partition@0 {
> > + label = "filesystem";
> > + reg = <0x0 0x0 0x100>;
> > + };
> > + (...)
> > + };
> > + };
> >
>
>
> --
> Best regards,
> Marek Vasut
Re: [PATCH 08/10] media: camss: Add files which handle the video device nodes
A few comments below:
On 11/25/2016 03:57 PM, Todor Tomov wrote:
> These files handle the video device nodes of the camss driver.
>
> Signed-off-by: Todor Tomov
> ---
> drivers/media/platform/qcom/camss-8x16/video.c | 597
> +
> drivers/media/platform/qcom/camss-8x16/video.h | 67 +++
> 2 files changed, 664 insertions(+)
> create mode 100644 drivers/media/platform/qcom/camss-8x16/video.c
> create mode 100644 drivers/media/platform/qcom/camss-8x16/video.h
>
> diff --git a/drivers/media/platform/qcom/camss-8x16/video.c
> b/drivers/media/platform/qcom/camss-8x16/video.c
> new file mode 100644
> index 000..0bf8ea9
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss-8x16/video.c
> @@ -0,0 +1,597 @@
> +static int video_start_streaming(struct vb2_queue *q, unsigned int count)
> +{
> + struct camss_video *video = vb2_get_drv_priv(q);
> + struct video_device *vdev = video->vdev;
> + struct media_entity *entity;
> + struct media_pad *pad;
> + struct v4l2_subdev *subdev;
> + int ret;
> +
> + ret = media_entity_pipeline_start(&vdev->entity, &video->pipe);
> + if (ret < 0)
> + return ret;
> +
> + ret = video_check_format(video);
> + if (ret < 0)
> + goto error;
> +
> + entity = &vdev->entity;
> + while (1) {
> + pad = &entity->pads[0];
> + if (!(pad->flags & MEDIA_PAD_FL_SINK))
> + break;
> +
> + pad = media_entity_remote_pad(pad);
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> + break;
> +
> + entity = pad->entity;
> + subdev = media_entity_to_v4l2_subdev(entity);
> +
> + ret = v4l2_subdev_call(subdev, video, s_stream, 1);
> + if (ret < 0 && ret != -ENOIOCTLCMD)
> + goto error;
> + }
> +
> + return 0;
> +
> +error:
> + media_entity_pipeline_stop(&vdev->entity);
> +
On error all queued buffers must be returned with state VB2_STATE_QUEUED.
Basically the same as 'camss_video_call(video, flush_buffers);', just with
a different state.
> + return ret;
> +}
> +static int video_querycap(struct file *file, void *fh,
> + struct v4l2_capability *cap)
> +{
> + strlcpy(cap->driver, "qcom-camss", sizeof(cap->driver));
> + strlcpy(cap->card, "Qualcomm Camera Subsystem", sizeof(cap->card));
> + strlcpy(cap->bus_info, "platform:qcom-camss", sizeof(cap->bus_info));
> + cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
> + V4L2_CAP_DEVICE_CAPS;
> + cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
Don't set capabilities and device_caps here. Instead fill in the struct
video_device
device_caps field and the v4l2 core will take care of cap->capabilities and
cap->device_caps.
> +
> + return 0;
> +}
> +
> +static int video_enum_fmt(struct file *file, void *fh, struct v4l2_fmtdesc
> *f)
> +{
> + struct camss_video *video = video_drvdata(file);
> + struct v4l2_format format;
> + int ret;
> +
> + if (f->type != video->type)
> + return -EINVAL;
> +
> + if (f->index)
> + return -EINVAL;
> +
> + ret = video_get_subdev_format(video, &format);
> + if (ret < 0)
> + return ret;
> +
> + f->pixelformat = format.fmt.pix.pixelformat;
> +
> + return 0;
> +}
> +
> +static int video_g_fmt(struct file *file, void *fh, struct v4l2_format *f)
> +{
> + struct camss_video *video = video_drvdata(file);
> +
> + if (f->type != video->type)
> + return -EINVAL;
> +
> + *f = video->active_fmt;
> +
> + return 0;
> +}
> +
> +static int video_s_fmt(struct file *file, void *fh, struct v4l2_format *f)
> +{
> + struct camss_video *video = video_drvdata(file);
> + int ret;
> +
> + if (f->type != video->type)
> + return -EINVAL;
> +
> + ret = video_get_subdev_format(video, f);
> + if (ret < 0)
> + return ret;
> +
> + video->active_fmt = *f;
> +
> + return 0;
> +}
> +
> +static int video_try_fmt(struct file *file, void *fh, struct v4l2_format *f)
> +{
> + struct camss_video *video = video_drvdata(file);
> +
> + if (f->type != video->type)
> + return -EINVAL;
> +
> + return video_get_subdev_format(video, f);
> +}
> +
> +static int video_enum_input(struct file *file, void *fh,
> + struct v4l2_input *input)
> +{
> + if (input->index > 0)
> + return -EINVAL;
> +
> + strlcpy(input->name, "camera", sizeof(input->name));
> + input->type = V4L2_INPUT_TYPE_CAMERA;
> +
> + return 0;
> +}
> +
> +static int video_g_input(struct file *file, void *fh, unsigned int *input)
> +{
> + *input = 0;
> +
> + return 0;
> +}
> +
> +static int video_s_input(struct file *file, void *fh, unsigned int input)
> +{
> + return input == 0
Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically
Michal Hocko wrote:
> __alloc_pages_may_oom makes sure to skip the OOM killer depending on
> the allocation request. This includes lowmem requests, costly high
> order requests and others. For a long time __GFP_NOFAIL acted as an
> override for all those rules. This is not documented and it can be quite
> surprising as well. E.g. GFP_NOFS requests are not invoking the OOM
> killer but GFP_NOFS|__GFP_NOFAIL does so if we try to convert some of
> the existing open coded loops around allocator to nofail request (and we
> have done that in the past) then such a change would have a non trivial
> side effect which is not obvious. Note that the primary motivation for
> skipping the OOM killer is to prevent from pre-mature invocation.
>
> The exception has been added by 82553a937f12 ("oom: invoke oom killer
> for __GFP_NOFAIL"). The changelog points out that the oom killer has to
> be invoked otherwise the request would be looping for ever. But this
> argument is rather weak because the OOM killer doesn't really guarantee
> any forward progress for those exceptional cases - e.g. it will hardly
> help to form costly order - I believe we certainly do not want to kill
> all processes and eventually panic the system just because there is a
> nasty driver asking for order-9 page with GFP_NOFAIL not realizing all
> the consequences - it is much better this request would loop for ever
> than the massive system disruption, lowmem is also highly unlikely to be
> freed during OOM killer and GFP_NOFS request could trigger while there
> is still a lot of memory pinned by filesystems.
I disagree. I believe that panic caused by OOM killer is much much better
than a locked up system. I hate to add new locations that can lockup inside
page allocator. This is __GFP_NOFAIL and reclaim has failed. Administrator
has to go in front of console and press SysRq-f until locked up situation
gets resolved is silly.
If there is a nasty driver asking for order-9 page with __GFP_NOFAIL, fix
that driver.
>
> This patch simply removes the __GFP_NOFAIL special case in order to have
> a more clear semantic without surprising side effects. Instead we do
> allow nofail requests to access memory reserves to move forward in both
> cases when the OOM killer is invoked and when it should be supressed.
> __alloc_pages_nowmark helper has been introduced for that purpose.
>
> Signed-off-by: Michal Hocko
[PATCH v2 4/4] ARM: dts: hix5hd2: add gmac generic compatible and clock names
Add gmac generic compatible and clock names.
Signed-off-by: Dongpo Li
---
arch/arm/boot/dts/hisi-x5hd2.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index fdcc23d..0da76c5 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -436,18 +436,20 @@
};
gmac0: ethernet@184 {
- compatible = "hisilicon,hix5hd2-gmac";
+ compatible = "hisilicon,hix5hd2-gemac",
"hisilicon,hisi-gemac-v1";
reg = <0x184 0x1000>,<0x184300c 0x4>;
interrupts = <0 71 4>;
clocks = <&clock HIX5HD2_MAC0_CLK>;
+ clock-names = "mac_core";
status = "disabled";
};
gmac1: ethernet@1841000 {
- compatible = "hisilicon,hix5hd2-gmac";
+ compatible = "hisilicon,hix5hd2-gemac",
"hisilicon,hisi-gemac-v1";
reg = <0x1841000 0x1000>,<0x1843010 0x4>;
interrupts = <0 72 4>;
clocks = <&clock HIX5HD2_MAC1_CLK>;
+ clock-names = "mac_core";
status = "disabled";
};
--
2.8.2
Re: [PATCH] vt: fix Scroll Lock LED trigger name
Hi!
> There is a disagreement between drivers/tty/vt/keyboard.c and
> drivers/input/input-leds.c with regard to what is a Scroll Lock LED
> trigger name: input calls it "kbd-scrolllock", but vt calls it
> "kbd-scrollock" (two l's).
> This prevents Scroll Lock LED trigger from binding to this LED by default.
>
> Since it is a scroLL Lock LED, this interface was introduced only about a
> year ago and in an Internet search people seem to reference this trigger
> only to set it to this LED let's simply rename it to "kbd-scrolllock".
>
> Also, it looks like this was supposed to be changed before this code was
> merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on
> the input side.
>
> Signed-off-by: Maciej S. Szmigiero
> ---
> drivers/tty/vt/keyboard.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index d5d81d4d3c04..3dd6a491cdba 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -982,7 +982,7 @@ static void kbd_led_trigger_activate(struct led_classdev
> *cdev)
> KBD_LED_TRIGGER((_led_bit) + 8, _name)
>
> static struct kbd_led_trigger kbd_led_triggers[] = {
> - KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrollock"),
> + KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrolllock"),
Would it be feasible to rename "VC_SCROLLOCK" to "VC_SCROLLLOCK", too?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Applied "ASoC: cs42l56: Fix misuse of regmap_update_bits" to the asoc tree
The patch ASoC: cs42l56: Fix misuse of regmap_update_bits has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 8c317fafdd4e3b988c44d986022c66cebf71fc41 Mon Sep 17 00:00:00 2001 From: Florian Vaussard Date: Tue, 29 Nov 2016 18:10:49 +0100 Subject: [PATCH] ASoC: cs42l56: Fix misuse of regmap_update_bits Using regmap_update_bits(..., mask, 1) with 'mask' following (1 << k) and k greater than 0 is wrong. Indeed, _regmap_update_bits will perform (mask & 1), which results in 0 if LSB of mask is 0. Thus the call regmap_update_bits(..., mask, 1) is in reality equivalent to regmap_update_bits(..., mask, 0). In such a case, the correct use is regmap_update_bits(..., mask, mask). This driver is performing such a mistake with the CS42L56_AIN*_REF_MASK masks, which equal 0x10, 0x20, 0x40 and 0x80. Fix the driver to make it consistent with the API. Please note that this change is untested, as I do not have this piece of hardware. Testers are welcome! Signed-off-by: Florian Vaussard Reviewed-by: Charles Keepax Acked-by: Brian Austin Signed-off-by: Mark Brown --- sound/soc/codecs/cs42l56.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/cs42l56.c b/sound/soc/codecs/cs42l56.c index 3e2c04642f1e..cb6ca85f1536 100644 --- a/sound/soc/codecs/cs42l56.c +++ b/sound/soc/codecs/cs42l56.c @@ -1277,19 +1277,23 @@ static int cs42l56_i2c_probe(struct i2c_client *i2c_client, if (cs42l56->pdata.ain1a_ref_cfg) regmap_update_bits(cs42l56->regmap, CS42L56_AIN_REFCFG_ADC_MUX, - CS42L56_AIN1A_REF_MASK, 1); + CS42L56_AIN1A_REF_MASK, + CS42L56_AIN1A_REF_MASK); if (cs42l56->pdata.ain1b_ref_cfg) regmap_update_bits(cs42l56->regmap, CS42L56_AIN_REFCFG_ADC_MUX, - CS42L56_AIN1B_REF_MASK, 1); + CS42L56_AIN1B_REF_MASK, + CS42L56_AIN1B_REF_MASK); if (cs42l56->pdata.ain2a_ref_cfg) regmap_update_bits(cs42l56->regmap, CS42L56_AIN_REFCFG_ADC_MUX, - CS42L56_AIN2A_REF_MASK, 1); + CS42L56_AIN2A_REF_MASK, + CS42L56_AIN2A_REF_MASK); if (cs42l56->pdata.ain2b_ref_cfg) regmap_update_bits(cs42l56->regmap, CS42L56_AIN_REFCFG_ADC_MUX, - CS42L56_AIN2B_REF_MASK, 1); + CS42L56_AIN2B_REF_MASK, + CS42L56_AIN2B_REF_MASK); if (cs42l56->pdata.micbias_lvl) regmap_update_bits(cs42l56->regmap, CS42L56_GAIN_BIAS_CTL, -- 2.10.2
Re: [PATCH 2/2] net: rfkill: Add rfkill-any LED trigger
> Thanks, these are obviously all valid concerns. Sorry for being > sloppy > with the ifdefs. If I get positive feedback on the proposed feature > itself, all these issues (and the warning pointed out in the other > message) will be resolved in v2. Looks fine, please do that. johannes
[PATCH v8 1/6] powerpc/qspinlock: powerpc support qspinlock
This patch add basic code to enable qspinlock on powerpc. qspinlock is
one kind of fairlock implementation. And seen some performance improvement
under some scenarios.
queued_spin_unlock() release the lock by just one write of NULL to the
::locked field which sits at different places in the two endianness
system.
We override some arch_spin_XXX as powerpc has io_sync stuff which makes
sure the io operations are protected by the lock correctly.
There is another special case, see commit
2c610022711 ("locking/qspinlock: Fix spin_unlock_wait() some more")
Signed-off-by: Pan Xinhui
---
arch/powerpc/include/asm/qspinlock.h | 66 +++
arch/powerpc/include/asm/spinlock.h | 31 +--
arch/powerpc/include/asm/spinlock_types.h | 4 ++
arch/powerpc/lib/locks.c | 59 +++
4 files changed, 147 insertions(+), 13 deletions(-)
create mode 100644 arch/powerpc/include/asm/qspinlock.h
diff --git a/arch/powerpc/include/asm/qspinlock.h
b/arch/powerpc/include/asm/qspinlock.h
new file mode 100644
index 000..4c89256
--- /dev/null
+++ b/arch/powerpc/include/asm/qspinlock.h
@@ -0,0 +1,66 @@
+#ifndef _ASM_POWERPC_QSPINLOCK_H
+#define _ASM_POWERPC_QSPINLOCK_H
+
+#include
+
+#define SPIN_THRESHOLD (1 << 15)
+#define queued_spin_unlock queued_spin_unlock
+#define queued_spin_is_locked queued_spin_is_locked
+#define queued_spin_unlock_wait queued_spin_unlock_wait
+
+extern void queued_spin_unlock_wait(struct qspinlock *lock);
+
+static inline u8 *__qspinlock_lock_byte(struct qspinlock *lock)
+{
+ return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
+}
+
+static inline void queued_spin_unlock(struct qspinlock *lock)
+{
+ /* release semantics is required */
+ smp_store_release(__qspinlock_lock_byte(lock), 0);
+}
+
+static inline int queued_spin_is_locked(struct qspinlock *lock)
+{
+ smp_mb();
+ return atomic_read(&lock->val);
+}
+
+#include
+
+/* we need override it as ppc has io_sync stuff */
+#undef arch_spin_trylock
+#undef arch_spin_lock
+#undef arch_spin_lock_flags
+#undef arch_spin_unlock
+#define arch_spin_trylock arch_spin_trylock
+#define arch_spin_lock arch_spin_lock
+#define arch_spin_lock_flags arch_spin_lock_flags
+#define arch_spin_unlock arch_spin_unlock
+
+static inline int arch_spin_trylock(arch_spinlock_t *lock)
+{
+ CLEAR_IO_SYNC;
+ return queued_spin_trylock(lock);
+}
+
+static inline void arch_spin_lock(arch_spinlock_t *lock)
+{
+ CLEAR_IO_SYNC;
+ queued_spin_lock(lock);
+}
+
+static inline
+void arch_spin_lock_flags(arch_spinlock_t *lock, unsigned long flags)
+{
+ CLEAR_IO_SYNC;
+ queued_spin_lock(lock);
+}
+
+static inline void arch_spin_unlock(arch_spinlock_t *lock)
+{
+ SYNC_IO;
+ queued_spin_unlock(lock);
+}
+#endif /* _ASM_POWERPC_QSPINLOCK_H */
diff --git a/arch/powerpc/include/asm/spinlock.h
b/arch/powerpc/include/asm/spinlock.h
index 8c1b913..954099e 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -60,6 +60,23 @@ static inline bool vcpu_is_preempted(int cpu)
}
#endif
+#if defined(CONFIG_PPC_SPLPAR)
+/* We only yield to the hypervisor if we are in shared processor mode */
+#define SHARED_PROCESSOR (lppaca_shared_proc(local_paca->lppaca_ptr))
+extern void __spin_yield(arch_spinlock_t *lock);
+extern void __rw_yield(arch_rwlock_t *lock);
+#else /* SPLPAR */
+#define __spin_yield(x)barrier()
+#define __rw_yield(x) barrier()
+#define SHARED_PROCESSOR 0
+#endif
+
+#ifdef CONFIG_QUEUED_SPINLOCKS
+#include
+#else
+
+#define arch_spin_relax(lock) __spin_yield(lock)
+
static __always_inline int arch_spin_value_unlocked(arch_spinlock_t lock)
{
return lock.slock == 0;
@@ -114,18 +131,6 @@ static inline int arch_spin_trylock(arch_spinlock_t *lock)
* held. Conveniently, we have a word in the paca that holds this
* value.
*/
-
-#if defined(CONFIG_PPC_SPLPAR)
-/* We only yield to the hypervisor if we are in shared processor mode */
-#define SHARED_PROCESSOR (lppaca_shared_proc(local_paca->lppaca_ptr))
-extern void __spin_yield(arch_spinlock_t *lock);
-extern void __rw_yield(arch_rwlock_t *lock);
-#else /* SPLPAR */
-#define __spin_yield(x)barrier()
-#define __rw_yield(x) barrier()
-#define SHARED_PROCESSOR 0
-#endif
-
static inline void arch_spin_lock(arch_spinlock_t *lock)
{
CLEAR_IO_SYNC;
@@ -203,6 +208,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t
*lock)
smp_mb();
}
+#endif /* !CONFIG_QUEUED_SPINLOCKS */
/*
* Read-write spinlocks, allowing multiple readers
* but only one writer.
@@ -338,7 +344,6 @@ static inline void arch_write_unlock(arch_rwlock_t *rw)
#define arch_read_lock_flags(lock, flags) arch_read_lock(lock)
#define arch_write_lock_flags(lock, flags) arch_write_lock(lock)
-#define arch_spin_relax(lock) __spin_yield(lock)
#define arch_read_relax(lock) __rw_yield(lock)
#define arch_writ
Re: [RFC PATCH] doc: change the way how the stable backport is requested
On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote: > On Mon 05-12-16 13:52:36, Greg KH wrote: > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > Currently if a patch should aim a stable tree backport one should add > > > > > > Cc: sta...@vger.kernel.org # $version > > > > > > to the s-o-b block. This has two major disadvantages a) it spams the > > > stable mailing list with patches which are just discussed and not merged > > > yet > > > > That's not a problem in that I know I like to see them to give me a > > "heads up" that something is coming down the pipeline soon. > > Are you really tracking all those discussion to catch resulting patches > in the Linus' tree? I simply fail to see a point having N versions of > the patch on the stable mailing list before it gets picked up from the > _Linus'_ anyayw. I do scan them, sometimes I even find problems with them (like a zram "fix" that went by this weekend.) So yes, it is always good to have more reviewers on patches, don't you think? > > I don't think anyone has ever complained of this before, do you? > > This is the reason I have stopped following the stable mailing list. > The noise level is just too high. What "noise"? It's all patches that are being addressed to the stable kernels, how is that off-topic? What do you expect to be posted to this list? > > > and b) it is easy to make a mistake and disclose a patch via > > > git-send-email while it is still discussed under security embargo. > > > > Having this happen only once (maybe twice) in a over a decade really > > isn't that bad of odds. We have loads of embargoed security patches > > that properly include the cc: stable tag, yet don't leak the patch to > > the public mailing list. So this really is a rare thing to have happen. > > Rare, still annoying and unnecessarily error prone. Btw. even git > send-email will not cope with Cc: stable # version properly... Here is > what I get when not using --suppress-cc=body on this particular patch > :From: Michal Hocko > :To: LKML > :Cc: Michal Hocko , > :sta...@vger.kernel.org, > :#, > :$version > :Subject: [RFC PATCH] doc: change the way how the stable backport is requested People are working on the "# 4.4+" issue in git right now, there was a thread about it last week. > > > In fact it is not necessary to have the stable mailing list address in > > > the Cc until it hits the Linus tree and all we need is to have a > > > grepable marker for automatic identification of such a patch. Let's > > > use > > > > > > stable-request: $version[s] > > > > > > instead. Where $version would tell which stable trees might be > > > interested in the backport. This will make the process much less error > > > prone without any actual downsides. > > > > We still have whole subsystems that have yet to learn about how to put > > proper "cc: stable@..." in their patches, why do we want to change the > > muscle memory of those that are doing the right thing to now have to do > > something else? > > I completely see this argument. It will take some time for people to > adapt any changes in the workflow. No question about that. I just > believe that a less error prone process would be more comfortable long > term. Making stable ML being only about stable related patches and the > follow up discussions sounds like an improvemnt to me as well. But the stable ML is only about stable related patches today, how would that change? thanks, greg k-h
Re: [PATCH 2/2] driver core: Silence device links sphinx warning
On Sun, Dec 04, 2016 at 01:10:04PM +0100, Lukas Wunner wrote: > Silence this warning emitted by sphinx: > include/linux/device.h:938: warning: No description found for parameter > 'links' > > While at it, fix typos in comments of device links code. > > Cc: Rafael J. Wysocki > Cc: Greg Kroah-Hartman > Cc: Jonathan Corbet > Cc: Silvio Fricke > Signed-off-by: Lukas Wunner > --- > drivers/base/core.c| 4 ++-- > include/linux/device.h | 1 + > 2 files changed, 3 insertions(+), 2 deletions(-) I'll take this patch now to keep the warnings from showing up in 4.10-rc1. thanks, greg k-h
Re: [patch net v2] net: fec: fix compile with CONFIG_M5272
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index 741cf4a57bfc..12aef1b15356 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -3301,7 +3301,7 @@ fec_probe(struct platform_device *pdev) /* Init network device */ ndev = alloc_etherdev_mqs(sizeof(struct fec_enet_private) + - FEC_STAT_SIZE, num_tx_qs, num_rx_qs); + FEC_STATS_SIZE, num_tx_qs, num_rx_qs); if (!ndev) return -ENOMEM; > Aieee I was typing too fast today, sorry... > > send separate "fix for the fix", or re-send patch without that silly typo? > > Nikita > >> Hi Nikita, >> >> [auto build test ERROR on net/master] >> >> url: >> https://github.com/0day-ci/linux/commits/Nikita-Yushchenko/net-fec-fix-compile-with-CONFIG_M5272/20161205-181735 >> config: arm-multi_v5_defconfig (attached as .config) >> compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 >> reproduce: >> wget >> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross >> -O ~/bin/make.cross >> chmod +x ~/bin/make.cross >> # save the attached .config to linux build tree >> make.cross ARCH=arm >> >> All errors (new ones prefixed by >>): >> >>drivers/net/ethernet/freescale/fec_main.c: In function 'fec_probe': >>>> drivers/net/ethernet/freescale/fec_main.c:3304:7: error: 'FEC_STAT_SIZE' >>>> undeclared (first use in this function) >> FEC_STAT_SIZE, num_tx_qs, num_rx_qs); >> ^ >>drivers/net/ethernet/freescale/fec_main.c:3304:7: note: each undeclared >> identifier is reported only once for each function it appears in >> >> vim +/FEC_STAT_SIZE +3304 drivers/net/ethernet/freescale/fec_main.c >> >> 3298 int num_rx_qs; >> 3299 >> 3300 fec_enet_get_queue_num(pdev, &num_tx_qs, &num_rx_qs); >> 3301 >> 3302 /* Init network device */ >> 3303 ndev = alloc_etherdev_mqs(sizeof(struct >> fec_enet_private) + >>> 3304 FEC_STAT_SIZE, num_tx_qs, >>> num_rx_qs); >> 3305 if (!ndev) >> 3306 return -ENOMEM; >> 3307 >> >> --- >> 0-DAY kernel test infrastructureOpen Source Technology Center >> https://lists.01.org/pipermail/kbuild-all Intel Corporation >>
Re: [patch net v2] net: fec: fix compile with CONFIG_M5272
Aieee I was typing too fast today, sorry... send separate "fix for the fix", or re-send patch without that silly typo? Nikita > Hi Nikita, > > [auto build test ERROR on net/master] > > url: > https://github.com/0day-ci/linux/commits/Nikita-Yushchenko/net-fec-fix-compile-with-CONFIG_M5272/20161205-181735 > config: arm-multi_v5_defconfig (attached as .config) > compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=arm > > All errors (new ones prefixed by >>): > >drivers/net/ethernet/freescale/fec_main.c: In function 'fec_probe': >>> drivers/net/ethernet/freescale/fec_main.c:3304:7: error: 'FEC_STAT_SIZE' >>> undeclared (first use in this function) > FEC_STAT_SIZE, num_tx_qs, num_rx_qs); > ^ >drivers/net/ethernet/freescale/fec_main.c:3304:7: note: each undeclared > identifier is reported only once for each function it appears in > > vim +/FEC_STAT_SIZE +3304 drivers/net/ethernet/freescale/fec_main.c > > 3298int num_rx_qs; > 3299 > 3300fec_enet_get_queue_num(pdev, &num_tx_qs, &num_rx_qs); > 3301 > 3302/* Init network device */ > 3303ndev = alloc_etherdev_mqs(sizeof(struct > fec_enet_private) + >> 3304 FEC_STAT_SIZE, num_tx_qs, num_rx_qs); > 3305if (!ndev) > 3306return -ENOMEM; > 3307 > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation >
Re: [POC/RFC PATCH] overlayfs: constant inode numbers
On Tue, Nov 29, 2016 at 11:49 PM, Miklos Szeredi wrote: > On Tue, Nov 29, 2016 at 1:03 PM, Amir Goldstein wrote: >> On Tue, Nov 29, 2016 at 1:34 PM, Amir Goldstein wrote: ... >>> Not sure that I understand what you are suggesting, but I would be happy >>> to make the needed adjustments to redirect_fh per your request if you >>> clarify >>> what you mean. From what I understand: >>> >>> 1. If redirect_dir=fh (and supported by layers), store lower handle >>> on dir copy up in new xattr OVL_XATTR_FH >>> 2. In ovl_rename(), set OVL_XATTR_REDIRECT regardless of OVL_XATTR_FH >>> 3. In ovl_lookup_single(), carry both d.redirct and d.redirect_fh to next >>> layer >>> 4. In ovl_lookup_layer(), lookup by handle first then by path >>> Miklos, FYI, this part of the work is done and pushed to #redirect_fh branch on my github. It is tested on same and not same fs and it is used as the base of current #ovl_snapshot branch and tested along with it. >>> not sure what you meant by "... and provide a good way to get the stable >>> ino." >>> Either I managed to confuse you, or I am missing something? > > I meant that we can unify OVL_XATTR_INO with "redirect/fh" > functionality and get something good out of it. > >> Perhaps you meant for non-dir: >> >> 5. If redirect_dir=fh, *propagate* lowest-handle on non-dir copy up >> 6. In ovl_lookup() of non-dir, decode lowest-handle to set oe->ino > > Yes. > > OVL_XATTR_FH would be safe to ignore, so this is back and forward > compatible.. And the cost is probably not prohitive, since copy ups > should be relatively rare. > I am still trying to figure out the best way of "getting something good" out of this merger, because changing ovl_getattr() to use redirect_fh instead of stored ino is not such a big win. More thought are welcome. Amir.
Re: Unkillable processes due to PTRACE_TRACEME again
On Mon, Dec 5, 2016 at 12:00 PM, Oleg Nesterov wrote:
> On 12/05, Oleg Nesterov wrote:
>>
>> On 12/02, Dmitry Vyukov wrote:
>> >
>> > I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
>> > the same unwaitable zombie processes.
>>
>> This is another thing, and notabug. This is how ptrace works,
>>
>> > void *thr(void *arg)
>> > {
>> > ptrace(PTRACE_TRACEME, 0, 0, 0);
>> > }
>> >
>> > int main()
>> > {
>> > int pid = fork();
>> > if (pid == 0) {
>> > pthread_t th;
>> > pthread_create(&th, 0, thr, 0);
>> > usleep(10);
>> > exit(0);
>> > }
>> > usleep(20);
>> > kill(pid, SIGKILL);
>> > int status = 0;
>> > waitpid(pid, &status, __WALL);
>>
>> waitpid(pid) hangs because you need to reap the sub-thread first.
>
> I'm afraid I wasn't clear...
>
> So the child process has 2 threads, the leader thread L and the sub-thread T.
> waitpid(pid == L->pid) will block until all the threads go away, but since T
> is
> traced it won't autoreap, the tracer should do waitpid(T->pid) first to reap
> this zombie. waitpid(-1) should work too.
Do you mean that I need to replace:
waitpid(pid, &status, __WALL);
with:
while (waitpid(-1, &status, __WALL) != pid) {}
?
It seems to work. But want to make sure.
Re: [PATCH 1/2] usb: host: xhci: Fix possible wild pointer when handling abort command
On 05.12.2016 09:51, Baolin Wang wrote:
When current command was supposed to be aborted, host will free the command
in handle_cmd_completion() function. But it might be still referenced by
xhci->current_cmd, which need to set NULL.
Signed-off-by: Baolin Wang
---
This patch is based on Lu Baolu's new fix patch:
usb: xhci: fix possible wild pointer
https://www.spinics.net/lists/linux-usb/msg150219.html
---
drivers/usb/host/xhci-ring.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 62dd1c7..9965a4c 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1362,8 +1362,11 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
*/
if (cmd_comp_code == COMP_CMD_ABORT) {
xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
- if (cmd->status == COMP_CMD_ABORT)
+ if (cmd->status == COMP_CMD_ABORT) {
+ if (xhci->current_cmd == cmd)
+ xhci->current_cmd = NULL;
goto event_handled;
+ }
}
cmd_type = TRB_FIELD_TO_TYPE(le32_to_cpu(cmd_trb->generic.field[3]));
True, thanks
-Mathias
Re: [PATCH 0/2] Device links documentation
[crazy CC list dropped] Can someone explain who the hell I ended up the on this stupid Cc long list for a reply to a mail I can't see either in my inbox or lkml folder?
Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically
On Mon 05-12-16 22:45:19, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > __alloc_pages_may_oom makes sure to skip the OOM killer depending on
> > the allocation request. This includes lowmem requests, costly high
> > order requests and others. For a long time __GFP_NOFAIL acted as an
> > override for all those rules. This is not documented and it can be quite
> > surprising as well. E.g. GFP_NOFS requests are not invoking the OOM
> > killer but GFP_NOFS|__GFP_NOFAIL does so if we try to convert some of
> > the existing open coded loops around allocator to nofail request (and we
> > have done that in the past) then such a change would have a non trivial
> > side effect which is not obvious. Note that the primary motivation for
> > skipping the OOM killer is to prevent from pre-mature invocation.
> >
> > The exception has been added by 82553a937f12 ("oom: invoke oom killer
> > for __GFP_NOFAIL"). The changelog points out that the oom killer has to
> > be invoked otherwise the request would be looping for ever. But this
> > argument is rather weak because the OOM killer doesn't really guarantee
> > any forward progress for those exceptional cases - e.g. it will hardly
> > help to form costly order - I believe we certainly do not want to kill
> > all processes and eventually panic the system just because there is a
> > nasty driver asking for order-9 page with GFP_NOFAIL not realizing all
> > the consequences - it is much better this request would loop for ever
> > than the massive system disruption, lowmem is also highly unlikely to be
> > freed during OOM killer and GFP_NOFS request could trigger while there
> > is still a lot of memory pinned by filesystems.
>
> I disagree. I believe that panic caused by OOM killer is much much better
> than a locked up system. I hate to add new locations that can lockup inside
> page allocator. This is __GFP_NOFAIL and reclaim has failed.
As a matter of fact any __GFP_NOFAIL can lockup inside the allocator.
Full stop. There is no guaranteed way to make a forward progress with
the current page allocator implementation.
So we are somewhere in the middle between pre-mature and pointless
system disruption (GFP_NOFS with a lots of metadata or lowmem request)
where the OOM killer even might not help and potential lockup which is
inevitable with the current design. Dunno about you but I would rather
go with the first option. To be honest I really fail to understand your
line of argumentation. We have this
do {
cond_resched();
} (page = alloc_page(GFP_NOFS));
vs.
page = alloc_page(GFP_NOFS | __GFP_NOFAIL);
the first one doesn't invoke OOM killer while the later does. This
discrepancy just cannot make any sense... The same is true for
alloc_page(GFP_DMA) vs alloc_page(GFP_DMA|__GFP_NOFAIL)
Now we can discuss whether it is a _good_ idea to not invoke OOM killer
for those exceptions but whatever we do __GFP_NOFAIL is not a way to
give such a subtle side effect. Or do you disagree even with that?
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/3] USB: OHCI: at91: remove useless extern declaration
On Sat, Dec 03, 2016 at 03:25:21AM +, csmanjuvi...@gmail.com wrote: > From: Manjunath Goudar > > Remove usb_disabled() extern declaration as it is already declared > as EXPORT_SYMBOL_GPL declaration in drivers/usb/core/usb.c The EXPORT_SYMBOL_GPL() has nothing to do with this, it's the fact that it is exported in include/linux/usb.h that matters. Please fix the text up and resend. thanks, greg k-h
Re: [PATCH 3/3] USB: OHCI: nxp: remove useless extern declaration
On Sat, Dec 03, 2016 at 03:25:23AM +, csmanjuvi...@gmail.com wrote: > From: Manjunath Goudar > > Remove usb_disabled() extern declaration as it is already declared > as EXPORT_SYMBOL_GPL declaration. And same thing again...
RE: [PATCH v6 2/2] mtd: nand: Add support for Arasan Nand Flash Controller
Hi Marek, Thanks for the review and comments. > -Original Message- > From: Marek Vasut [mailto:marek.va...@gmail.com] > Sent: Monday, December 05, 2016 10:10 AM > To: Punnaiah Choudary Kalluri ; > dw...@infradead.org; computersforpe...@gmail.com; > boris.brezil...@free-electrons.com; rich...@nod.at; > cyrille.pitc...@atmel.com; robh...@kernel.org; mark.rutl...@arm.com > Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; > devicet...@vger.kernel.org; Michal Simek ; > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah > Choudary Kalluri > Subject: Re: [PATCH v6 2/2] mtd: nand: Add support for Arasan Nand Flash > Controller > > On 12/05/2016 05:11 AM, Punnaiah Choudary Kalluri wrote: > > Added the basic driver for Arasan Nand Flash Controller used in > > Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit > > correction. > > Ummm, NAND, ECC, can you fix the acronyms to be in caps ? > Ok > > Signed-off-by: Punnaiah Choudary Kalluri > > --- > > Chnages in v6: > > - Addressed most of the Brian and Boris comments > > - Separated the nandchip from the nand controller > > - Removed the ecc lookup table from driver > > - Now use framework nand waitfunction and readoob > > - Fixed the compiler warning > > - Adapted the new frameowrk changes related to ecc and ooblayout > > - Disabled the clocks after the nand_reelase > > - Now using only one completion object > > - Boris suggessions like adapting cmd_ctrl and rework on read/write byte > > are not implemented and i will patch them later > > - Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr > will > > implement later once the basic driver is mainlined. > > Changes in v5: > > - Renamed the driver filei as arasan_nand.c > > - Fixed all comments relaqted coding style > > - Fixed comments related to propagating the errors > > - Modified the anfc_write_page_hwecc as per the write_page > > prototype > > Changes in v4: > > - Added support for onfi timing mode configuration > > - Added clock suort > > - Added support for multiple chipselects > > Changes in v3: > > - Removed unused variables > > - Avoided busy loop and used jifies based implementation > > - Fixed compiler warnings "right shift count >= width of type" > > - Removed unneeded codei and improved error reporting > > - Added onfi version check to ensure reading the valid address cycles > > Changes in v2: > > - Added missing of.h to avoid kbuild system report erro > > --- > > drivers/mtd/nand/Kconfig | 8 + > > drivers/mtd/nand/Makefile | 1 + > > drivers/mtd/nand/arasan_nand.c | 974 > + > > 3 files changed, 983 insertions(+) > > create mode 100644 drivers/mtd/nand/arasan_nand.c > > > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > > index 7b7a887..e831f4e 100644 > > --- a/drivers/mtd/nand/Kconfig > > +++ b/drivers/mtd/nand/Kconfig > > @@ -569,4 +569,12 @@ config MTD_NAND_MTK > > Enables support for NAND controller on MTK SoCs. > > This controller is found on mt27xx, mt81xx, mt65xx SoCs. > > > > +config MTD_NAND_ARASAN > > + tristate "Support for Arasan Nand Flash controller" > > + depends on HAS_IOMEM > > + depends on HAS_DMA > > + help > > + Enables the driver for the Arasan Nand Flash controller on > > + Zynq UltraScale+ MPSoC. > > + > > endif # MTD_NAND > > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > > index cafde6f..44b8b00 100644 > > --- a/drivers/mtd/nand/Makefile > > +++ b/drivers/mtd/nand/Makefile > > @@ -58,5 +58,6 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= > hisi504_nand.o > > obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ > > obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o > > obj-$(CONFIG_MTD_NAND_MTK) += mtk_nand.o mtk_ecc.o > > +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nand.o > > Keep the list at least reasonably sorted. Ok > > > nand-objs := nand_base.o nand_bbt.o nand_timings.o > > diff --git a/drivers/mtd/nand/arasan_nand.c > b/drivers/mtd/nand/arasan_nand.c > > new file mode 100644 > > index 000..6b0670e > > --- /dev/null > > +++ b/drivers/mtd/nand/arasan_nand.c > > @@ -0,0 +1,974 @@ > > +/* > > + * Arasan Nand Flash Controller Driver > > NAND > > > + * Copyright (C) 2014 - 2015 Xilinx, Inc. > > It's 2016 now ... Sorry :). Yes, I will update. > > > + * This program is free software; you can redistribute it and/or modify it > under > > + * the terms of the GNU General Public License version 2 as published by > the > > + * Free Software Foundation; either version 2 of the License, or (at your > > + * option) any later version. > > + */ > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define DRIVER_NAME"arasan_nand" > > +#define EVNT_TIMEOUT 1000 > > Rena
Re: [PATCH 2/3] USB: OHCI: omap: remove useless extern declaration
On Sat, Dec 03, 2016 at 03:25:22AM +, csmanjuvi...@gmail.com wrote: > From: Manjunath Goudar > > Remove usb_disabled() and ocpi_enable() extern declaration > as it is already declared as EXPORT_SYMBOL_GPL declaration. Same here, EXPORT_SYMBOL* doesn't matter for stuff like this. thanks, greg k-h
RE: [PATCH v6 1/2] mtd: arasan: Add device tree binding documentation
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com]
> Sent: Monday, December 05, 2016 2:07 PM
> To: Marek Vasut
> Cc: Punnaiah Choudary Kalluri ;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> cyrille.pitc...@atmel.com; robh...@kernel.org; mark.rutl...@arm.com;
> linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> devicet...@vger.kernel.org; Michal Simek ;
> kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah
> Choudary Kalluri
> Subject: Re: [PATCH v6 1/2] mtd: arasan: Add device tree binding
> documentation
>
> On Mon, 5 Dec 2016 05:25:54 +0100
> Marek Vasut wrote:
>
> > On 12/05/2016 05:11 AM, Punnaiah Choudary Kalluri wrote:
> > > This patch adds the dts binding document for arasan nand flash
> > > controller.
> > >
> > > Signed-off-by: Punnaiah Choudary Kalluri
> > > Acked-by: Rob Herring
> > > ---
> > > changes in v6:
> > > - Removed num-cs property
> > > - Separated nandchip from nand controller changes in v5:
> > > - None
> > > Changes in v4:
> > > - Added num-cs property
> > > - Added clock support
> > > Changes in v3:
> > > - None
> > > Changes in v2:
> > > - None
> > > ---
> > > .../devicetree/bindings/mtd/arasan_nfc.txt | 38
> ++
> > > 1 file changed, 38 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > > b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > > new file mode 100644
> > > index 000..dcbe7ad
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > > @@ -0,0 +1,38 @@
> > > +Arasan Nand Flash Controller with ONFI 3.1 support
> >
> > Arasan NAND Flash ...
> >
> > > +Required properties:
> > > +- compatible: Should be "arasan,nfc-v3p10"
> >
> > This v3p10 looks like version 3 patchlevel 10, but shouldn't we have
> > some fallback option which doesn't encode IP version in the compat
> > string ?
>
> Not necessarily. Usually you define a generic compatible when you have
> other reliable means to detect the IP version (a version register for
> example).
> If you can't detect that at runtime, then providing only specific compatible
> strings is a good solution to avoid breaking the DT ABI.
Yes. I am also thinking the same. Arasan controller doesn't have the register
to indicate the IP version number.
>
> >
> > Also, shouldn't quirks be handled by DT props instead of effectively
> > encoding them into the compatible string ?
>
> Well, from my experience, it's better to hide as much as possible behind the
> compatible. This way, if new quirks are needed for a specific revision, you
> can
> update the driver without having to change the DT.
>
Agree.
Regards,
Punnaiah
> >
> > > +- reg: Memory map for module access
> > > +- interrupt-parent: Interrupt controller the interrupt is routed
> > > +through
> > > +- interrupts: Should contain the interrupt for the device
> > > +- clock-name: List of input clocks - "clk_sys", "clk_flash"
> > > + (See clock bindings for details)
> > > +- clocks: Clock phandles (see clock bindings for details)
> > > +
> > > +Optional properties:
> > > +- arasan,has-mdma: Enables Dma support
> >
> > 'Enables DMA support' , with DMA in caps.
> >
> > > +for nand partition information please refer the below file
> >
> > For NAND ...
> >
> > > +Documentation/devicetree/bindings/mtd/partition.txt
> > > +
> > > +Example:
> > > + nand0: nand@ff10 {
> > > + compatible = "arasan,nfc-v3p10"
> > > + reg = <0x0 0xff10 0x1000>;
> > > + clock-name = "clk_sys", "clk_flash"
> > > + clocks = <&misc_clk &misc_clk>;
> > > + interrupt-parent = <&gic>;
> > > + interrupts = <0 14 4>;
> > > + arasan,has-mdma;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>
> > > +
> > > + nand@0 {
> > > + reg = <0>
> > > + partition@0 {
> > > + label = "filesystem";
> > > + reg = <0x0 0x0 0x100>;
> > > + };
> > > + (...)
> > > + };
> > > + };
> > >
> >
> >
Re: [PATCH 3/3] USB: OHCI: nxp: remove useless extern declaration
On Sat, Dec 03, 2016 at 03:25:23AM +, csmanjuvi...@gmail.com wrote: > From: Manjunath Goudar > > Remove usb_disabled() extern declaration as it is already declared > as EXPORT_SYMBOL_GPL declaration. merge this with your first patch please, it belongs with it.
Re: ILP32 for ARM64 - testing with lmbench
On Mon, Dec 05, 2016 at 06:16:09PM +0800, Zhangjian (Bamvor) wrote: > Do you have suggestion of next move of upstreaming ILP32? I mentioned the steps a few time before. I'm pasting them again here: 1. Complete the review of the Linux patches and ABI (no merge yet) 2. Review the corresponding glibc patches (no merge yet) 3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more than just busybox) to be able to reproduce the testing in ARM 4. More testing (LTP, trinity, performance regressions etc.) 5. Move the ILP32 PCS out of beta (based on the results from 4) 6. Check the market again to see if anyone still needs ILP32 7. Based on 6, decide whether to merge the kernel and glibc patches What's not explicitly mentioned in step 4 is glibc testing. Point 5 is ARM's responsibility (toolchain folk). > There are already the test results of lmbench and specint. Do you they > are ok or need more data to prove no regression? I would need to reproduce the tests myself, see step 3. > I have also noticed that there are ILP32 failures in glibc testsuite. > Is it the only blocker for merge ILP32(in technology part)? It's probably not the only blocker but I have to review the kernel patches again to make sure. I'd also like to see whether the libc-alpha community is ok with the glibc counterpart (but don't merge the patches until the ABI is agreed on both sides). On performance, I want to make sure there are no regressions on AArch32/compat and AArch64/LP64. -- Catalin
Re: [PATCH 2/3] serial: st-asc: Provide RTS functionality
Hi Lee
On 12/02/2016 03:11 PM, Lee Jones wrote:
> Until this point, it has not been possible for serial applications
> to toggle the UART RTS line. This can be useful with certain
> configurations. For example, when using a Mezzanine on a Linaro
> 96board, RTS line is used to take the the on-board microcontroller
typo "the the on"
> in and out of reset.
>
> Signed-off-by: Lee Jones
> ---
> drivers/tty/serial/st-asc.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
> index 379e5bd..ce46898 100644
> --- a/drivers/tty/serial/st-asc.c
> +++ b/drivers/tty/serial/st-asc.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
>
> #define DRIVER_NAME "st-asc"
> #define ASC_SERIAL_NAME "ttyAS"
> @@ -38,6 +39,7 @@
>
> struct asc_port {
> struct uart_port port;
> + struct gpio_desc *rts;
> struct clk *clk;
> unsigned int hw_flow_control:1;
> unsigned int force_m1:1;
> @@ -381,12 +383,16 @@ static unsigned int asc_tx_empty(struct uart_port *port)
>
> static void asc_set_mctrl(struct uart_port *port, unsigned int mctrl)
> {
> + struct asc_port *ascport = to_asc_port(port);
> +
> /*
>* This routine is used for seting signals of: DTR, DCD, CTS/RTS
>* We use ASC's hardware for CTS/RTS, so don't need any for that.
>* Some boards have DTR and DCD implemented using PIO pins,
>* code to do this should be hooked in here.
>*/
> +
> + gpiod_set_value(ascport->rts, mctrl & TIOCM_RTS);
> }
>
> static unsigned int asc_get_mctrl(struct uart_port *port)
> @@ -731,12 +737,20 @@ MODULE_DEVICE_TABLE(of, asc_match);
> static int asc_serial_probe(struct platform_device *pdev)
> {
> int ret;
> + struct device_node *np = pdev->dev.of_node;
> struct asc_port *ascport;
> + struct gpio_desc *gpiod;
>
> ascport = asc_of_get_asc_port(pdev);
> if (!ascport)
> return -ENODEV;
>
> + gpiod = devm_get_gpiod_from_child(&pdev->dev, "rts", &np->fwnode);
> + if (!IS_ERR(gpiod)) {
> + gpiod_direction_output(gpiod, 0);
> + ascport->rts = gpiod;
> + }
> +
> ret = asc_init_port(ascport, pdev);
> if (ret)
> return ret;
>
Re: [RFC PATCH] doc: change the way how the stable backport is requested
On Mon 05-12-16 14:58:24, Greg KH wrote: > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote: > > On Mon 05-12-16 13:52:36, Greg KH wrote: > > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote: > > > > From: Michal Hocko > > > > > > > > Currently if a patch should aim a stable tree backport one should add > > > > > > > > Cc: sta...@vger.kernel.org # $version > > > > > > > > to the s-o-b block. This has two major disadvantages a) it spams the > > > > stable mailing list with patches which are just discussed and not merged > > > > yet > > > > > > That's not a problem in that I know I like to see them to give me a > > > "heads up" that something is coming down the pipeline soon. > > > > Are you really tracking all those discussion to catch resulting patches > > in the Linus' tree? I simply fail to see a point having N versions of > > the patch on the stable mailing list before it gets picked up from the > > _Linus'_ anyayw. > > I do scan them, sometimes I even find problems with them (like a zram > "fix" that went by this weekend.) So yes, it is always good to have > more reviewers on patches, don't you think? Yes I do agree that more review is better. But then the stable mailing list is a complete failure in that resopect - at least for me. Why? Simply because it doesn't contain discussion for the stable inclusion but rather something that eventually might happen to become stable material. This what I call noise and the reason why I've stopped following the stable ML. > > > I don't think anyone has ever complained of this before, do you? > > > > This is the reason I have stopped following the stable mailing list. > > The noise level is just too high. > > What "noise"? It's all patches that are being addressed to the stable > kernels, how is that off-topic? What do you expect to be posted to this > list? Patches which are final and target the stable tree. I do not have to see N versions of patchesets which evolve in the time just to see that something completely different has been merged to the Linus tree. -- Michal Hocko SUSE Labs
[PATCH] kasan: add test for -fsanitize-address-use-after-scope
From: marxin
In commit 828347f8f9a5 ("kasan: support use-after-scope detection") we
added support for use-after-scope. Let's add a check if it actually
works.
Signed-off-by: Martin Liska
Signed-off-by: Jiri Slaby
---
lib/test_kasan.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index fbdf87920093..32f31b8d306e 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -352,6 +352,19 @@ static noinline void __init kasan_stack_oob(void)
*(volatile char *)p;
}
+static noinline void __init kasan_stack_use_after_scope(void)
+{
+ char *ptr = NULL;
+ {
+ char a;
+
+ ptr = &a;
+ }
+
+ pr_info("use-after-scope on stack\n");
+ *(volatile char *)ptr;
+}
+
static noinline void __init ksize_unpoisons_memory(void)
{
char *ptr;
@@ -461,6 +474,7 @@ static int __init kmalloc_tests_init(void)
kmalloc_uaf2();
kmem_cache_oob();
kasan_stack_oob();
+ kasan_stack_use_after_scope();
kasan_global_oob();
ksize_unpoisons_memory();
copy_user_test();
--
2.11.0
Re: [PATCH 0/2] Device links documentation
Hi Christoph, Em Mon, 5 Dec 2016 06:08:16 -0800 Christoph Hellwig escreveu: > [crazy CC list dropped] > > Can someone explain who the hell I ended up the on this stupid > Cc long list for a reply to a mail I can't see either in my > inbox or lkml folder? Not sure why Lukas added you to the C/C. On the original e-mail, you're c/c. That's what it was on PATCH 0/2 from Lukas: From: Lukas Wunner Date: Sun, 4 Dec 2016 13:10:04 +0100 Subject: [PATCH 0/2] Device links documentation To: "Rafael J. Wysocki" , Greg Kroah-Hartman , Jonathan Corbet , Silvio Fricke Cc: "Luis R. Rodriguez" , Marek Szyprowski , Bartlomiej Zolnierkiewicz , Andrzej Hajda , "Mauro Carvalho Chehab" , Inki Dae , Joerg Roedel , Kukjin Kim , Krzysztof Kozlowski , Mark Brown , Tomeu Vizoso , Kevin Hilman , Ulf Hansson , Geert Uytterhoeven , Tobias Jakobi , Tomasz Figa , Grant Likely , Laurent Pinchart , Lars-Peter Clausen , Dmitry Torokhov , Christoph Hellwig , Arnd Bergmann , Alan Stern , Hanjun Guo , linux...@vger.kernel.org, li...@s-opensource.com, -ker...@vger.kernel.org, io...@lists.linux-foundation.org, linux-samsung-...@vger.kernel.org LKML was not c/c. Instead, Lukas seemed to send it to: li...@s-opensource.com, -ker...@vger.kernel.org clearly a script error or a typo, as, AFAIKT, neither one of the above emails exist. I corrected it on my reply, as claws-mail complained about that. -- Thanks, Mauro
Re: [RFC PATCH] doc: change the way how the stable backport is requested
On Mon, Dec 05, 2016 at 03:14:51PM +0100, Michal Hocko wrote: > On Mon 05-12-16 14:58:24, Greg KH wrote: > > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote: > > > On Mon 05-12-16 13:52:36, Greg KH wrote: > > > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote: > > > > > From: Michal Hocko > > > > > > > > > > Currently if a patch should aim a stable tree backport one should add > > > > > > > > > > Cc: sta...@vger.kernel.org # $version > > > > > > > > > > to the s-o-b block. This has two major disadvantages a) it spams the > > > > > stable mailing list with patches which are just discussed and not > > > > > merged > > > > > yet > > > > > > > > That's not a problem in that I know I like to see them to give me a > > > > "heads up" that something is coming down the pipeline soon. > > > > > > Are you really tracking all those discussion to catch resulting patches > > > in the Linus' tree? I simply fail to see a point having N versions of > > > the patch on the stable mailing list before it gets picked up from the > > > _Linus'_ anyayw. > > > > I do scan them, sometimes I even find problems with them (like a zram > > "fix" that went by this weekend.) So yes, it is always good to have > > more reviewers on patches, don't you think? > > Yes I do agree that more review is better. But then the stable mailing > list is a complete failure in that resopect - at least for me. Why? > Simply because it doesn't contain discussion for the stable inclusion > but rather something that eventually might happen to become stable > material. This what I call noise and the reason why I've stopped > following the stable ML. That doesn't make sense, I want to see patches that are being proposed for the stable kernels _before_ they get into the maintainers and Linus's tree, as then, it is almost always too late. I will point out the zram patch this weekend as an example of that, where if the original had gone in, it would be a while before the "fixup" would have then gone in, and the abi deprecation would probably have missed 4.11 entirely. Don't you want to catch things earlier rather than later? thanks, greg k-h
Re: [PATCH] kasan: add test for -fsanitize-address-use-after-scope
On 12/05/2016, 03:16 PM, Jiri Slaby wrote:
> From: marxin
>
> In commit 828347f8f9a5 ("kasan: support use-after-scope detection") we
> added support for use-after-scope. Let's add a check if it actually
> works.
Nah, scratch that, 828347f8f9a5 added also a test which I overlooked.
thanks,
--
js
suse labs
Re: [PATCH] kasan: add test for -fsanitize-address-use-after-scope
On Mon, Dec 5, 2016 at 3:16 PM, Jiri Slaby wrote:
> From: marxin
>
> In commit 828347f8f9a5 ("kasan: support use-after-scope detection") we
> added support for use-after-scope. Let's add a check if it actually
> works.
>
> Signed-off-by: Martin Liska
> Signed-off-by: Jiri Slaby
> ---
> lib/test_kasan.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> index fbdf87920093..32f31b8d306e 100644
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -352,6 +352,19 @@ static noinline void __init kasan_stack_oob(void)
> *(volatile char *)p;
> }
>
> +static noinline void __init kasan_stack_use_after_scope(void)
> +{
> + char *ptr = NULL;
> + {
> + char a;
> +
> + ptr = &a;
> + }
> +
> + pr_info("use-after-scope on stack\n");
> + *(volatile char *)ptr;
> +}
> +
> static noinline void __init ksize_unpoisons_memory(void)
> {
> char *ptr;
> @@ -461,6 +474,7 @@ static int __init kmalloc_tests_init(void)
> kmalloc_uaf2();
> kmem_cache_oob();
> kasan_stack_oob();
> + kasan_stack_use_after_scope();
> kasan_global_oob();
> ksize_unpoisons_memory();
> copy_user_test();
> --
> 2.11.0
I might be missing something, but my patch contained a test:
+static noinline void __init use_after_scope_test(void)
+{
+ volatile char *volatile p;
+
+ pr_info("use-after-scope on int\n");
+ {
+ int local = 0;
+
+ p = (char *)&local;
+ }
+ p[0] = 1;
+ p[3] = 1;
+
+ pr_info("use-after-scope on array\n");
+ {
+ char local[1024] = {0};
+
+ p = local;
+ }
+ p[0] = 1;
+ p[1023] = 1;
+}
+
Re: scsi: use-after-free in bio_copy_from_iter
On Sat, Dec 3, 2016 at 7:19 PM, Johannes Thumshirn wrote: > On Sat, Dec 03, 2016 at 04:22:39PM +0100, Dmitry Vyukov wrote: >> On Sat, Dec 3, 2016 at 11:38 AM, Johannes Thumshirn >> wrote: >> > On Fri, Dec 02, 2016 at 05:50:39PM +0100, Dmitry Vyukov wrote: >> >> On Fri, Nov 25, 2016 at 8:08 PM, Dmitry Vyukov wrote: > > [...] > > Hi Dmitry, > >> >> Thanks for looking into this! >> >> As I noted I don't think this is use-after-free, more likely it is an >> out-of-bounds access against non-slab range. >> >> Report says that we are copying 0x1000 bytes starting at 0x880062c6e02a. >> The first bad address is 0x880062c6f000, this address was freed >> previously and that's why KASAN reports UAF. > > We're copying 65499 bytes (65535 - sizeof(sg_header)) and we've got 2 order 3 > page allocations to do this. It fails somewhere in there. I have seen fails at > 0x2000, 0xe000 and all (0x1000 aligned) offsets inbetween. > >> But this is already next page, and KASAN does not insert redzones >> around pages (only around slab allocations). >> So most likely the code should have not touch 0x880062c6f000 as it >> is not his memory. >> Also I noticed that the report happens after few minutes of repeatedly >> running this program, so I would expect that this is some kind of race >> -- either between kernel threads, or maybe between user space threads >> and kernel. > > I somehow think it's a race as well, especially as I have to run the > reproducer in an endless loop and break out of it once I have the 1st > stacktrace in dmesg. This takes between some minutes up to one hour on my > setup. > > But the race against a userspace thread... Could it be that the reproducer has > already exited it's threads while the copy_from_iter() is still running? > Normally I'd say no, as user-space shouldn't run while the kernel is doing > things in it's address space, but this is highly suspicious. > >> Or maybe it's just that the next page is not always marked >> as free, so we just don't detect the bad access. > > Could be, but I lack the memory management knowledge to say more than a 'could > be'. > >> >> Does it all make any sense to you? >> Can you think of any additional sanity checks that will ensure that >> this code copies only memory it owns? > > Given that we pass the 0x as dxfer_len it thinks it owns all memory, so > this is OK, kinda. All that could be would be that user-space has already > exited and thus it's memory is already freed. The crash happens in the context of sendfile syscall, we the address space should be alive. But the crash happens on address 0x880062c6f000 which is not a user-space address, right? This is something that kernel has allocated previously. Do you have CONFIG_DEBUG_PAGEALLOC enabled? I have it enabled. Maybe it increases changes of triggering the bug. Do we know where that memory that we are copying was allocated? Is it slab or page alloc? We could extend KASAN output with more details. E.g. print allocation stack for the _first_ byte of memcpy, or memorize page alloc/free stacks in page struct using lib/stackdepot.c.
Re: [PATCH 4/4] KVM: x86: allow hotplug of VCPU with APIC ID over 0xff
Am 02.12.2016 um 20:44 schrieb Radim Krčmář: LAPIC after reset is in xAPIC mode, which poses a problem for hotplug of VCPUs with high APIC ID, because reset VCPU is waiting for INIT/SIPI, but there is no way to uniquely address it using xAPIC. From many possible options, we chose the one that also works on real hardware: accepting interrupts addressed to LAPIC's x2APIC ID even in xAPIC mode. KVM intentionally differs from real hardware, because real hardware (Knights Landing) does just "x2apic_id & 0xff" to decide whether to accept the interrupt in xAPIC mode and it can deliver one interrupt to more than one physical destination, e.g. 0x123 to 0x123 and 0x23. Add a capability to let userspace know that we do something now. Should we allow user space to turn it on/off for compatibility handling? Or do we just not care? (or how will this capability be used later on?) -- David
Re: [RFC PATCH] doc: change the way how the stable backport is requested
On Mon 05-12-16 15:21:37, Greg KH wrote: > On Mon, Dec 05, 2016 at 03:14:51PM +0100, Michal Hocko wrote: > > On Mon 05-12-16 14:58:24, Greg KH wrote: > > > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote: > > > > On Mon 05-12-16 13:52:36, Greg KH wrote: > > > > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote: > > > > > > From: Michal Hocko > > > > > > > > > > > > Currently if a patch should aim a stable tree backport one should > > > > > > add > > > > > > > > > > > > Cc: sta...@vger.kernel.org # $version > > > > > > > > > > > > to the s-o-b block. This has two major disadvantages a) it spams the > > > > > > stable mailing list with patches which are just discussed and not > > > > > > merged > > > > > > yet > > > > > > > > > > That's not a problem in that I know I like to see them to give me a > > > > > "heads up" that something is coming down the pipeline soon. > > > > > > > > Are you really tracking all those discussion to catch resulting patches > > > > in the Linus' tree? I simply fail to see a point having N versions of > > > > the patch on the stable mailing list before it gets picked up from the > > > > _Linus'_ anyayw. > > > > > > I do scan them, sometimes I even find problems with them (like a zram > > > "fix" that went by this weekend.) So yes, it is always good to have > > > more reviewers on patches, don't you think? > > > > Yes I do agree that more review is better. But then the stable mailing > > list is a complete failure in that resopect - at least for me. Why? > > Simply because it doesn't contain discussion for the stable inclusion > > but rather something that eventually might happen to become stable > > material. This what I call noise and the reason why I've stopped > > following the stable ML. > > That doesn't make sense, I want to see patches that are being proposed > for the stable kernels _before_ they get into the maintainers and > Linus's tree, as then, it is almost always too late. Too late for what? I am still not sure I see your point. Are you suggesting that a review from the stable mailing list, which wouldn't be a part of a standard review process normally, has helped to identify issues? > I will point out the zram patch this weekend as an example of that, > where if the original had gone in, it would be a while before the > "fixup" would have then gone in, and the abi deprecation would probably > have missed 4.11 entirely. I do not have a full context here. Do you have a pointer please? > Don't you want to catch things earlier rather than later? Sure, but I fail to see the role of the stable ML in this area. I might be underastimating its role of course. -- Michal Hocko SUSE Labs
Re: [PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
On Tue, Nov 29, 2016 at 5:57 AM, Bartosz Golaszewski
wrote:
> Add the dumb-vga-dac node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 58
>
> arch/arm/boot/dts/da850.dtsi | 17
> 2 files changed, 75 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
> b/arch/arm/boot/dts/da850-lcdk.dts
> index 711b9ad..d864f11 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -50,6 +50,53 @@
> system-clock-frequency = <24576000>;
> };
> };
> +
> + vga_bridge {
s/_/-/
> + compatible = "dumb-vga-dac";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
Are these pins from the LCD controller? They should be part of the LCD
controller node.
Rob
Re: [PATCH net-next v4 2/4] dt-bindings: net: add EEE capability constants
On Mon, Nov 28, 2016 at 04:50:26PM +0100, Jerome Brunet wrote: > Signed-off-by: Jerome Brunet > Tested-by: Yegor Yefremov > Tested-by: Andreas Färber > Tested-by: Neil Armstrong > --- > include/dt-bindings/net/mdio.h | 19 +++ > 1 file changed, 19 insertions(+) > create mode 100644 include/dt-bindings/net/mdio.h Seems changes are wanted on this, but patches 2 and 3 should be combined. The header is part of the binding doc. Rob
Re: [PATCH 1/4] KVM: x86: use delivery to self in hyperv synic
Am 02.12.2016 um 20:43 schrieb Radim Krčmář: Interrupt to self can sent without knowing the APIC ID. can _be_ sent? Looks sane to me. Reviewed-by: David Hildenbrand -- David
Re: [PATCH 08/10] media: camss: Add files which handle the video device nodes
Hi Hans,
On Monday 05 Dec 2016 14:44:55 Hans Verkuil wrote:
> > +static int video_querycap(struct file *file, void *fh,
> > + struct v4l2_capability *cap)
> > +{
> > + strlcpy(cap->driver, "qcom-camss", sizeof(cap->driver));
> > + strlcpy(cap->card, "Qualcomm Camera Subsystem", sizeof(cap->card));
> > + strlcpy(cap->bus_info, "platform:qcom-camss",
> > sizeof(cap->bus_info));
> > + cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
> > + V4L2_CAP_DEVICE_CAPS
> > ;
> > + cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
>
> Don't set capabilities and device_caps here. Instead fill in the struct
> video_device device_caps field and the v4l2 core will take care of
> cap->capabilities and cap->device_caps.
Time to add this to checkpatch.pl ? :-)
> > +
> > + return 0;
> > +}
--
Regards,
Laurent Pinchart
Re: [RFC PATCH] doc: change the way how the stable backport is requested
On Mon, Dec 05, 2016 at 03:39:15PM +0100, Michal Hocko wrote: > On Mon 05-12-16 15:21:37, Greg KH wrote: > > On Mon, Dec 05, 2016 at 03:14:51PM +0100, Michal Hocko wrote: > > > On Mon 05-12-16 14:58:24, Greg KH wrote: > > > > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote: > > > > > On Mon 05-12-16 13:52:36, Greg KH wrote: > > > > > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote: > > > > > > > From: Michal Hocko > > > > > > > > > > > > > > Currently if a patch should aim a stable tree backport one should > > > > > > > add > > > > > > > > > > > > > > Cc: sta...@vger.kernel.org # $version > > > > > > > > > > > > > > to the s-o-b block. This has two major disadvantages a) it spams > > > > > > > the > > > > > > > stable mailing list with patches which are just discussed and not > > > > > > > merged > > > > > > > yet > > > > > > > > > > > > That's not a problem in that I know I like to see them to give me a > > > > > > "heads up" that something is coming down the pipeline soon. > > > > > > > > > > Are you really tracking all those discussion to catch resulting > > > > > patches > > > > > in the Linus' tree? I simply fail to see a point having N versions of > > > > > the patch on the stable mailing list before it gets picked up from the > > > > > _Linus'_ anyayw. > > > > > > > > I do scan them, sometimes I even find problems with them (like a zram > > > > "fix" that went by this weekend.) So yes, it is always good to have > > > > more reviewers on patches, don't you think? > > > > > > Yes I do agree that more review is better. But then the stable mailing > > > list is a complete failure in that resopect - at least for me. Why? > > > Simply because it doesn't contain discussion for the stable inclusion > > > but rather something that eventually might happen to become stable > > > material. This what I call noise and the reason why I've stopped > > > following the stable ML. > > > > That doesn't make sense, I want to see patches that are being proposed > > for the stable kernels _before_ they get into the maintainers and > > Linus's tree, as then, it is almost always too late. > > Too late for what? I am still not sure I see your point. Are you > suggesting that a review from the stable mailing list, which wouldn't > be a part of a standard review process normally, has helped to identify > issues? Sometimes, yes, this happens. > > I will point out the zram patch this weekend as an example of that, > > where if the original had gone in, it would be a while before the > > "fixup" would have then gone in, and the abi deprecation would probably > > have missed 4.11 entirely. > > I do not have a full context here. Do you have a pointer please? A patch for the zram subsystem was cc: stable this weekend and I pointed out problems with it and the user/kernel api that it was modifying. I would have never seen this patch otherwise. > > Don't you want to catch things earlier rather than later? > > Sure, but I fail to see the role of the stable ML in this area. I might > be underastimating its role of course. I think you are :) Seeing the patches sent to the list _before_ they end up in a maintainers tree, or Linus's tree, helps some issues to be resolved. Most of the time it just lets me know what to watch out for, and what areas of the kernel are having lots of issues. Given that the current maintainers of the stable kernels don't seem to be objecting to the current setup of this list, I find it odd that you wish to change it :) thanks, greg k-h
Re: [PATCH v2 2/2] eeprom: Add IDT 89HPESx driver bindings file
On Tue, Nov 29, 2016 at 01:38:21AM +0300, Serge Semin wrote:
> See cover-letter for changelog
>
> Signed-off-by: Serge Semin
>
> ---
> .../devicetree/bindings/misc/idt_89hpesx.txt | 41
> ++
There's not a better location for this? I can't tell because you don't
describe what the device is.
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/idt_89hpesx.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/idt_89hpesx.txt
> b/Documentation/devicetree/bindings/misc/idt_89hpesx.txt
> index 000..469cc93
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/idt_89hpesx.txt
> @@ -0,0 +1,41 @@
> +EEPROM / CSR SMBus-slave interface of IDT 89HPESx devices
> +
> +Required properties:
> + - compatible : should be ","
> + Basically there is only one manufacturer: idt, but some
> + compatible devices may be produced in future. Following devices
> + are supported: 89hpes8nt2, 89hpes12nt3, 89hpes24nt6ag2,
> + 89hpes32nt8ag2, 89hpes32nt8bg2, 89hpes12nt12g2, 89hpes16nt16g2,
> + 89hpes24nt24g2, 89hpes32nt24ag2, 89hpes32nt24bg2;
> + 89hpes12n3, 89hpes12n3a, 89hpes24n3, 89hpes24n3a;
> + 89hpes32h8, 89hpes32h8g2, 89hpes48h12, 89hpes48h12g2,
> + 89hpes48h12ag2, 89hpes16h16, 89hpes22h16, 89hpes22h16g2,
> + 89hpes34h16, 89hpes34h16g2, 89hpes64h16, 89hpes64h16g2,
> + 89hpes64h16ag2;
> + 89hpes12t3g2, 89hpes24t3g2, 89hpes16t4, 89hpes4t4g2,
> + 89hpes10t4g2, 89hpes16t4g2, 89hpes16t4ag2, 89hpes5t5,
> + 89hpes6t5, 89hpes8t5, 89hpes8t5a, 89hpes24t6, 89hpes6t6g2,
> + 89hpes24t6g2, 89hpes16t7, 89hpes32t8, 89hpes32t8g2,
> + 89hpes48t12, 89hpes48t12g2.
> + Current implementation of the driver doesn't have any device-
Driver capabilties are irrelevant to bindings.
> + specific functionalities. But since each of them differs
> + by registers mapping, CSRs read/write restrictions can be
> + added in future.
> + - reg : I2C address of the IDT 89HPES device.
> +
> +Optional properties:
> + - read-only : Parameterless property disables writes to the EEPROM
> + - idt,eesize : Size of EEPROM device connected to IDT 89HPES i2c-master bus
> + (default value is 4096 bytes if option isn't specified)
> + - idt,eeaddr : Custom address of EEPROM device
> + (If not specified IDT 89HPESx device will try to communicate
> + with EEPROM sited by default address - 0x50)
Don't we already have standard EEPROM properties that could be used
here?
> +
> +Example:
> + idt_pcie_sw@60 {
Don't use '_'.
> + compatible = "idt,89hpes12nt3";
> + reg = <0x60>;
> + read-only;
> + idt,eesize = <65536>;
> + idt,eeaddr = <0x50>;
> + };
> --
> 2.6.6
>
Re: [PATCH 4.8 14/37] drm/amdgpu: fix power state when port pm is unavailable
On Mon, Dec 05, 2016 at 01:11:25AM +0100, Peter Wu wrote: > On Wed, Nov 30, 2016 at 12:53:19PM +0100, Greg Kroah-Hartman wrote: > > On Wed, Nov 30, 2016 at 11:51:00AM +0100, Peter Wu wrote: > [..] > > > Please delay this patch (amd tje mext radeon patch, 15/37), it contains > > > a regression for which these patches (from drm-fixes) are needed: > > > > > > drm/radeon: fix check for port PM availability > > > drm/amdgpu: fix check for port PM availability > > > > > > Patches should appear in v4.9-rc8 via > > > https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes > > > > Thanks for letting me know, both are now dropped. Please let me and > > sta...@vger.kernel.org know when it is safe to add these back. > > Patches entered mainline, please consider these patches for backporting > to 4.8: > > 1db4496f167b drm/amdgpu: fix power state when port pm is unavailable > d3ac31f3b4bf drm/radeon: fix power state when port pm is unavailable (v2) > > 7ac33e47d576 drm/amdgpu: fix check for port PM availability > bcfdd5d51050 drm/radeon: fix check for port PM availability All now queued up, thanks. greg k-h
RE: [PATCH V2 09/13] perf script: show kernel overhead
> On Fri, Dec 02, 2016 at 04:19:17PM -0500, kan.li...@intel.com wrote:
> > From: Kan Liang
> >
> > Shows kernel overhead in perf script.
> >
> > The output is as below:
> >
> > perf script --show-profiling-cost-events
> > perf 29001 79989.093958: 1 cycles:
> > 81064ca6 native_write_msr (/lib/
> >sleep 29001 79989.094282: 7661 cycles:
> > 810dc433 update_blocked_averages
> >sleep 29001 79989.094294: 7442 cycles:
> > 81810f60 irq_work_interrupt (/li
> >sleep 29001 79989.094305: 25466 cycles:
> > 813ca410 radix_tree_next_chunk (
> >sleep 29001 79989.094340: 94368 cycles:
> > 8180fa90 page_fault (/lib/module
> >sleep 29001 79989.094459: 167362 cycles:
> > 811e3f79 alloc_set_pte (/lib/mod
> >sleep 29001 79989.094672: 190283 cycles:
> > 7f5d7c91d8e7 _dl_addr (/usr/lib64/li
> >sleep 29001 79991.094978: 194526 cycles:
> > 811e0579 __tlb_remove_page_size.
> >sleep 29001 79991.095061: PERF_RECORD_OVERHEAD [SAMPLE] nr:
> 8
> > time: 28110
> >sleep 29001 79991.095062: PERF_RECORD_OVERHEAD [SB] nr: 24
> > time: 41397
>
> hi,
> got segfault by running:
>
> [jolsa@ibm-x3650m4-01 perf]$ catchsegv ./perf --no-pager script --show-
> profiling-cost-events
>
Thanks for the testing.
I only test it with kernel overhead event, but not redo the test after
adding the user overhead event. :(
The user overhead event doesn't have sample. So it's not supported for now.
The patch as below will fix it. I will include the fix in V3.
BTW: perf script patch is a stand along patch. It would not impact other
patches.
I think you can still play with the rest of V2 patches.
Thanks,
Kan
--
>From 03360f4083c30a19f8985ac07893e65e8de7a355 Mon Sep 17 00:00:00 2001
From: Kan Liang
Date: Mon, 5 Dec 2016 08:56:28 -0500
Subject: [PATCH 09/13] perf script: show kernel overhead
Shows kernel overhead in perf script.
The output is as below:
perf script --show-profiling-cost-events
perf 29001 79989.093958: 1 cycles:
81064ca6 native_write_msr (/lib/
sleep 29001 79989.094282: 7661 cycles:
810dc433 update_blocked_averages
sleep 29001 79989.094294: 7442 cycles:
81810f60 irq_work_interrupt (/li
sleep 29001 79989.094305: 25466 cycles:
813ca410 radix_tree_next_chunk (
sleep 29001 79989.094340: 94368 cycles:
8180fa90 page_fault (/lib/module
sleep 29001 79989.094459: 167362 cycles:
811e3f79 alloc_set_pte (/lib/mod
sleep 29001 79989.094672: 190283 cycles:
7f5d7c91d8e7 _dl_addr (/usr/lib64/li
sleep 29001 79991.094978: 194526 cycles:
811e0579 __tlb_remove_page_size.
sleep 29001 79991.095061: PERF_RECORD_OVERHEAD [SAMPLE] nr: 8
time: 28110
sleep 29001 79991.095062: PERF_RECORD_OVERHEAD [SB] nr: 24
time: 41397
Signed-off-by: Kan Liang
---
tools/perf/Documentation/perf-script.txt | 3 +++
tools/perf/builtin-script.c | 36
tools/perf/util/event.c | 29 +
tools/perf/util/event.h | 1 +
4 files changed, 69 insertions(+)
diff --git a/tools/perf/Documentation/perf-script.txt
b/tools/perf/Documentation/perf-script.txt
index c01904f..b371023 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -289,6 +289,9 @@ include::itrace.txt[]
--force::
Don't do ownership validation.
+--show-profiling-cost-events::
+ Display perf profiling time cost related event (PERF_RECORD_OVERHEAD)
+
SEE ALSO
linkperf:perf-record[1], linkperf:perf-script-perl[1],
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index e1daff3..01019de 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -829,6 +829,7 @@ struct perf_script {
boolshow_task_events;
boolshow_mmap_events;
boolshow_switch_events;
+ boolshow_profiling_cost_events;
boolallocated;
struct cpu_map *cpus;
struct thread_map *threads;
@@ -1264,6 +1265,37 @@ static int process_switch_event(struct perf_tool *tool,
return 0;
}
+static int process_overhead_event(struct perf_tool *tool,
+ union perf_event *event,
+ struct perf_sample *sample,
+ struct machine *machine)
+{
+ struct thread *thread;
+ struct perf_script *script = container_of(tool, struct perf_script,
tool);
+ struct perf_session *session = script->session;
+ struct perf_evsel *evsel;
+
+ if (perf_event__process_overh
Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available [ver #3]
On Sun, Dec 4, 2016 at 6:33 PM, Al Viro wrote: > On Sun, Dec 04, 2016 at 04:38:05AM +, Al Viro wrote: > >> I understand wanting to avoid extra arguments, but you are asking for trouble >> with that sort of calling conventions. Verifying that all call chains have >> these fields initialized is bloody unpleasant and it *is* going to break, >> especially since the rules are "you need to initialize it for vfs_xgetattr(), >> but not for vfs_getattr()" - the names are similar enough for confusion, >> and that's not the only such pair. > > FWIW, there's a bit of abuse of struct kstat in overlayfs object > creation paths - for one thing, it ends up with a very small subset > of struct kstat (mode + rdev), for another it also needs link in > case of symlinks and ends up passing it separately. > > IMO it would be better to introduce a separate object for that; does anybody > have objections to something like the patch below? In principle, we might > even lift that thing into general API and switch > ->mkdir()/->mknod()/->symlink() > to identical calling conventions. Hell knows, perhaps ->create() as well... > Comments? Good cleanup. Applied, thanks. Miklos
Re: [PATCH 1/6] net: ethernet: ti: netcp: add support of cpts
On Mon, Nov 28, 2016 at 05:04:23PM -0600, Grygorii Strashko wrote: > From: WingMan Kwok > > This patch adds support of the cpts device found in the > gbe and 10gbe ethernet switches on the keystone 2 SoCs > (66AK2E/L/Hx, 66AK2Gx). > > Signed-off-by: WingMan Kwok > Signed-off-by: Grygorii Strashko > --- > .../devicetree/bindings/net/keystone-netcp.txt | 9 + > drivers/net/ethernet/ti/Kconfig| 7 +- > drivers/net/ethernet/ti/netcp.h| 2 +- > drivers/net/ethernet/ti/netcp_core.c | 18 +- > drivers/net/ethernet/ti/netcp_ethss.c | 437 > - > 5 files changed, 459 insertions(+), 14 deletions(-) > > diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt > b/Documentation/devicetree/bindings/net/keystone-netcp.txt > index 04ba1dc..c37b54e 100644 > --- a/Documentation/devicetree/bindings/net/keystone-netcp.txt > +++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt > @@ -113,6 +113,15 @@ Optional properties: > will only initialize these ports and attach PHY > driver to them if needed. > > + Properties related to cpts configurations. > + - cpts_clock_mult/cpts_clock_shift: Needs vendor prefix. Don't use '_'. > + used for converting time counter cycles to ns as in > + > + ns = (cycles * clock_mult) >> _shift > + > + Defaults: clock_mult, clock_shift = calculated from > + CPTS refclk What does this mean? > + > NetCP interface properties: Interface specification for NetCP sub-modules. > Required properties: > - rx-channel:the navigator packet dma channel name for rx.
Re: [PATCH 2/6] net: ethernet: ti: cpts: add support for ext rftclk selection
On Mon, Nov 28, 2016 at 05:04:24PM -0600, Grygorii Strashko wrote: > Some CPTS instances, which can be found on KeyStone 2 1/10G Ethernet > Switch Subsystems, can control an external multiplexer that selects > one of up to 32 clocks for time sync reference (RFTCLK). This feature > can be configured through CPTS_RFTCLK_SEL register (offset: x08). > > Hence, introduce optional DT cpts_rftclk_sel poperty wich, if present, > will specify CPTS reference clock. The cpts_rftclk_sel should be > omitted in DT if HW doesn't support this feature. The external fixed > rate clocks can be defined in board files as "fixed-clock". > > Signed-off-by: Grygorii Strashko > --- > Documentation/devicetree/bindings/net/keystone-netcp.txt | 2 ++ Please group binding changes into a single patch. > drivers/net/ethernet/ti/cpts.c | 12 > drivers/net/ethernet/ti/cpts.h | 8 +++- > 3 files changed, 21 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt > b/Documentation/devicetree/bindings/net/keystone-netcp.txt > index c37b54e..ec4a241 100644 > --- a/Documentation/devicetree/bindings/net/keystone-netcp.txt > +++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt > @@ -114,6 +114,8 @@ Optional properties: > driver to them if needed. > > Properties related to cpts configurations. > + - cpts-rftclk-sel: selects one of up to 32 clocks for time sync > + reference. Default = 0. Vendor prefix. > - cpts_clock_mult/cpts_clock_shift: > used for converting time counter cycles to ns as in >
[PATCH v3 2/3] ARM: dts: vf610-zii-dev: Add .dts file for rev. C
Add .dts file for rev. C of the board by factoring out commonalities
into a shared include file (vf610-zii-dev-rev-b-c.dtsi) and deriving
revision specific file from it (vf610-zii-dev-rev-b.dts and
vf610-zii-dev-reb-c.dts).
Signed-off-by: Andrey Smirnov
---
Changes since v2:
- Removed unnecessary "ethernet-phy-id0022.1550" string from
ethernet-phy@0 node
- Correctecd IRQ_TYPE_EDGE_FALLING to IRQ_TYPE_LEVEL_LOW in
ethernet-phy@0, since that's what KS8091 corresponding to
that node uses
- Changed PTB28's pinmux configuration to include a 47kOhm
pullup to pull aforementioned PHY IRQ line to unasserted
level by default
arch/arm/boot/dts/Makefile| 3 +-
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 300 +--
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 394 ++
arch/arm/boot/dts/vf610-zii-dev.dtsi | 383 +
4 files changed, 780 insertions(+), 300 deletions(-)
create mode 100644 arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
create mode 100644 arch/arm/boot/dts/vf610-zii-dev.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..9f0d2a1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -442,7 +442,8 @@ dtb-$(CONFIG_SOC_VF610) += \
vf610-cosmic.dtb \
vf610m4-cosmic.dtb \
vf610-twr.dtb \
- vf610-zii-dev-rev-b.dtb
+ vf610-zii-dev-rev-b.dtb \
+ vf610-zii-dev-rev-c.dtb
dtb-$(CONFIG_ARCH_MXS) += \
imx23-evk.dtb \
imx23-olinuxino.dtb \
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 2210811..c0fc3f2 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -43,32 +43,12 @@
*/
/dts-v1/;
-#include "vf610.dtsi"
+#include "vf610-zii-dev.dtsi"
/ {
model = "ZII VF610 Development Board, Rev B";
compatible = "zii,vf610dev-b", "zii,vf610dev", "fsl,vf610";
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory {
- reg = <0x8000 0x2000>;
- };
-
- gpio-leds {
- compatible = "gpio-leds";
- pinctrl-0 = <&pinctrl_leds_debug>;
- pinctrl-names = "default";
-
- debug {
- label = "zii:green:debug1";
- gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- };
- };
-
mdio-mux {
compatible = "mdio-mux-gpio";
pinctrl-0 = <&pinctrl_mdio_mux>;
@@ -281,25 +261,6 @@
};
};
- reg_vcc_3v3_mcu: regulator-vcc-3v3-mcu {
- compatible = "regulator-fixed";
- regulator-name = "vcc_3v3_mcu";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- };
-
- usb0_vbus: regulator-usb0-vbus {
- compatible = "regulator-fixed";
- pinctrl-0 = <&pinctrl_usb_vbus>;
- regulator-name = "usb_vbus";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- enable-active-high;
- regulator-always-on;
- regulator-boot-on;
- gpio = <&gpio0 6 0>;
- };
-
spi0 {
compatible = "spi-gpio";
pinctrl-0 = <&pinctrl_gpio_spi0>;
@@ -336,49 +297,6 @@
};
};
-&adc0 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_adc0_ad5>;
- vref-supply = <®_vcc_3v3_mcu>;
- status = "okay";
-};
-
-&edma0 {
- status = "okay";
-};
-
-&esdhc1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_esdhc1>;
- bus-width = <4>;
- status = "okay";
-};
-
-&fec0 {
- phy-mode = "rmii";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec0>;
- status = "okay";
-};
-
-&fec1 {
- phy-mode = "rmii";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec1>;
- status = "okay";
-
- fixed-link {
- speed = <100>;
- full-duplex;
- };
-
- mdio1: mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- status = "okay";
- };
-};
-
&i2c0 {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -403,33 +321,6 @@
interrupt-parent = <&gpio2>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
};
-
- lm75@48 {
- compatible = "national,lm75";
- reg = <0x48>;
- };
-
- at24c04@50 {
- compatible = "atmel,24c04";
- reg = <0x50>;
- };
-
- at24c04@52 {
- compatible = "atmel,24c0
Re: [PATCH 08/10] media: camss: Add files which handle the video device nodes
Hello,
On Monday 05 Dec 2016 14:44:55 Hans Verkuil wrote:
> On 11/25/2016 03:57 PM, Todor Tomov wrote:
> > These files handle the video device nodes of the camss driver.
> >
> > Signed-off-by: Todor Tomov
> > ---
> >
> > drivers/media/platform/qcom/camss-8x16/video.c | 597
> > drivers/media/platform/qcom/camss-8x16/video.h | 67 +++
> > 2 files changed, 664 insertions(+)
> > create mode 100644 drivers/media/platform/qcom/camss-8x16/video.c
> > create mode 100644 drivers/media/platform/qcom/camss-8x16/video.h
[snip]
> > +int msm_video_register(struct camss_video *video, struct v4l2_device
> > *v4l2_dev,
> > +const char *name)
> > +{
> > + struct media_pad *pad = &video->pad;
> > + struct video_device *vdev;
> > + struct vb2_queue *q;
> > + int ret;
> > +
> > + vdev = video_device_alloc();
> > + if (vdev == NULL) {
> > + dev_err(v4l2_dev->dev, "Failed to allocate video device\n");
> > + return -ENOMEM;
> > + }
> > +
> > + video->vdev = vdev;
> > +
> > + q = &video->vb2_q;
> > + q->drv_priv = video;
> > + q->mem_ops = &vb2_dma_contig_memops;
> > + q->ops = &msm_video_vb2_q_ops;
> > + q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> > + q->io_modes = VB2_MMAP;
>
> Add modes VB2_DMABUF and VB2_READ. These are for free, so why not?
> Especially DMABUF is of course very desirable to have.
I certainly agree with VB2_DMABUF, but I wouldn't expose VB2_READ. read() for
this kind of device is inefficient and we should encourage userspace
application to move away from it (and certainly make it very clear that new
applications should not use read() with this device).
> > + q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > + q->buf_struct_size = sizeof(struct camss_buffer);
> > + q->dev = video->camss->dev;
> > + ret = vb2_queue_init(q);
> > + if (ret < 0) {
> > + dev_err(v4l2_dev->dev, "Failed to init vb2 queue\n");
> > + return ret;
> > + }
> > +
> > + pad->flags = MEDIA_PAD_FL_SINK;
> > + ret = media_entity_pads_init(&vdev->entity, 1, pad);
> > + if (ret < 0) {
> > + dev_err(v4l2_dev->dev, "Failed to init video entity\n");
> > + goto error_media_init;
> > + }
> > +
> > + vdev->fops = &msm_vid_fops;
> > + vdev->ioctl_ops = &msm_vid_ioctl_ops;
> > + vdev->release = video_device_release;
> > + vdev->v4l2_dev = v4l2_dev;
> > + vdev->vfl_dir = VFL_DIR_RX;
> > + vdev->queue = &video->vb2_q;
>
> As mentioned in querycap: set vdev->device_caps here.
>
> > + strlcpy(vdev->name, name, sizeof(vdev->name));
> > +
> > + ret = video_register_device(vdev, VFL_TYPE_GRABBER, -1);
> > + if (ret < 0) {
> > + dev_err(v4l2_dev->dev, "Failed to register video device\n");
> > + goto error_video_register;
> > + }
> > +
> > + video_set_drvdata(vdev, video);
> > +
> > + return 0;
> > +
> > +error_video_register:
> > + media_entity_cleanup(&vdev->entity);
> > +error_media_init:
> > + vb2_queue_release(&video->vb2_q);
> > +
> > + return ret;
> > +}
--
Regards,
Laurent Pinchart
[PATCH v3 1/3] ARM: dts: vf610-zii-dev-rev-b: Remove leftover PWM pingroup
Remove pwm0grp since it is:
a) Not referenced anywhere in the DTS file (unlike Tower board it
is based on, this board does not use/expose FTM0)
b) Configures PTB2 and PTB3 in a way that contradicts
pinctrl-mdio-mux
Signed-off-by: Andrey Smirnov
---
Changes since v2:
- None
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index fa19cfd..2210811 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -677,15 +677,6 @@
>;
};
- pinctrl_pwm0: pwm0grp {
- fsl,pins = <
- VF610_PAD_PTB0__FTM0_CH00x1582
- VF610_PAD_PTB1__FTM0_CH10x1582
- VF610_PAD_PTB2__FTM0_CH20x1582
- VF610_PAD_PTB3__FTM0_CH30x1582
- >;
- };
-
pinctrl_qspi0: qspi0grp {
fsl,pins = <
VF610_PAD_PTD7__QSPI0_B_QSCK0x31c3
--
2.5.5
Re: [RFC PATCH] doc: change the way how the stable backport is requested
On Mon 05-12-16 15:43:59, Greg KH wrote: > On Mon, Dec 05, 2016 at 03:39:15PM +0100, Michal Hocko wrote: > > On Mon 05-12-16 15:21:37, Greg KH wrote: > > > On Mon, Dec 05, 2016 at 03:14:51PM +0100, Michal Hocko wrote: > > > > On Mon 05-12-16 14:58:24, Greg KH wrote: > > > > > On Mon, Dec 05, 2016 at 02:05:08PM +0100, Michal Hocko wrote: > > > > > > On Mon 05-12-16 13:52:36, Greg KH wrote: > > > > > > > On Mon, Dec 05, 2016 at 08:21:54AM +0100, Michal Hocko wrote: > > > > > > > > From: Michal Hocko > > > > > > > > > > > > > > > > Currently if a patch should aim a stable tree backport one > > > > > > > > should add > > > > > > > > > > > > > > > > Cc: sta...@vger.kernel.org # $version > > > > > > > > > > > > > > > > to the s-o-b block. This has two major disadvantages a) it > > > > > > > > spams the > > > > > > > > stable mailing list with patches which are just discussed and > > > > > > > > not merged > > > > > > > > yet > > > > > > > > > > > > > > That's not a problem in that I know I like to see them to give me > > > > > > > a > > > > > > > "heads up" that something is coming down the pipeline soon. > > > > > > > > > > > > Are you really tracking all those discussion to catch resulting > > > > > > patches > > > > > > in the Linus' tree? I simply fail to see a point having N versions > > > > > > of > > > > > > the patch on the stable mailing list before it gets picked up from > > > > > > the > > > > > > _Linus'_ anyayw. > > > > > > > > > > I do scan them, sometimes I even find problems with them (like a zram > > > > > "fix" that went by this weekend.) So yes, it is always good to have > > > > > more reviewers on patches, don't you think? > > > > > > > > Yes I do agree that more review is better. But then the stable mailing > > > > list is a complete failure in that resopect - at least for me. Why? > > > > Simply because it doesn't contain discussion for the stable inclusion > > > > but rather something that eventually might happen to become stable > > > > material. This what I call noise and the reason why I've stopped > > > > following the stable ML. > > > > > > That doesn't make sense, I want to see patches that are being proposed > > > for the stable kernels _before_ they get into the maintainers and > > > Linus's tree, as then, it is almost always too late. > > > > Too late for what? I am still not sure I see your point. Are you > > suggesting that a review from the stable mailing list, which wouldn't > > be a part of a standard review process normally, has helped to identify > > issues? > > Sometimes, yes, this happens. It is really hard to argue here... But effectivelly something is really broken when wrong/unsuitable patches marked for stable pass the maintainer. > > > I will point out the zram patch this weekend as an example of that, > > > where if the original had gone in, it would be a while before the > > > "fixup" would have then gone in, and the abi deprecation would probably > > > have missed 4.11 entirely. > > > > I do not have a full context here. Do you have a pointer please? > > A patch for the zram subsystem was cc: stable this weekend and I pointed > out problems with it and the user/kernel api that it was modifying. I > would have never seen this patch otherwise. I guess you are talking about https://lkml.org/lkml/2016/12/3/257? If yes then the patch hasn't even been taken by Andrew so I am wondering why do mention it as a hand break coming from the stable tree. > > > Don't you want to catch things earlier rather than later? > > > > Sure, but I fail to see the role of the stable ML in this area. I might > > be underastimating its role of course. > > I think you are :) > > Seeing the patches sent to the list _before_ they end up in a > maintainers tree, or Linus's tree, helps some issues to be resolved. > Most of the time it just lets me know what to watch out for, and what > areas of the kernel are having lots of issues. > > Given that the current maintainers of the stable kernels don't seem to > be objecting to the current setup of this list, I find it odd that you > wish to change it :) The reason I came up with this is simple and I have mentioned that in the changelog. I just thought we might improve the process a bit, if there is no demand for that then I will not push for it. This is an RFC after all. -- Michal Hocko SUSE Labs
[PATCH] USB: cdc-acm: add device id for GW Instek AFG-125
Add device-id entry for GW Instek AFG-125, which has a byte swapped
bInterfaceSubClass (0x20).
Signed-off-by: Nathaniel Quillin
---
drivers/usb/class/cdc-acm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index fada988..c5ff13f 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1719,6 +1719,7 @@ static const struct usb_device_id acm_ids[] = {
{ USB_DEVICE(0x20df, 0x0001), /* Simtec Electronics Entropy Key */
.driver_info = QUIRK_CONTROL_LINE_STATE, },
{ USB_DEVICE(0x2184, 0x001c) }, /* GW Instek AFG-2225 */
+ { USB_DEVICE(0x2184, 0x0036) }, /* GW Instek AFG-125 */
{ USB_DEVICE(0x22b8, 0x6425), /* Motorola MOTOMAGX phones */
},
/* Motorola H24 HSPA module: */
--
2.8.0.rc3.226.g39d4020
Re: [PATCH 0/2] Device links documentation
On Mon, Dec 05, 2016 at 06:08:16AM -0800, Christoph Hellwig wrote: > [crazy CC list dropped] > > Can someone explain who the hell I ended up the on this stupid > Cc long list for a reply to a mail I can't see either in my > inbox or lkml folder? You were cc'ed on this series but the messages bounced: : host casper.infradead.org[85.118.1.10] said: 550 Invalid address in message header. Consult RFC2822. (in reply to end of DATA command) LKML was cc'ed as well but I can't see the series in the web archives, perhaps it was filtered due to the length of the Cc: header. Indeed the cc list was lengthy, whether crazily or stupidly so I don't know. I cc'ed everyone that was pulled into the device links discussion in November to allow them to comment on the documentation. You were pulled in by Luis in this e-mail: https://www.spinics.net/lists/kernel/msg2380422.html Best regards, Lukas
Re: [PATCH] block: fix unintended fallthrough in generic_make_request_checks()
On 12/04/2016 06:56 AM, Nicolai Stange wrote:
> Since commit e73c23ff736e ("block: add async variant of
> blkdev_issue_zeroout") messages like the following show up:
>
> EXT4-fs (dm-1): Delayed block allocation failed for inode 2368848 at
> logical offset 0 with max blocks 1 with error 95
> EXT4-fs (dm-1): This should not happen!! Data will be lost
>
> Due to the following fallthrough introduced with
> commit 2d253440b5af ("block: Define zoned block device operations"),
> generic_make_request_checks() would accept a REQ_OP_WRITE_SAME bio only
> if the block device supports "write same" *and* is a zoned one:
>
> switch (bio_op(bio)) {
> [...]
> case REQ_OP_WRITE_SAME:
> if (!bdev_write_same(bio->bi_bdev))
> goto not_supported;
> case REQ_OP_ZONE_REPORT:
> case REQ_OP_ZONE_RESET:
> if (!bdev_is_zoned(bio->bi_bdev))
> goto not_supported;
> break;
> [...]
> }
>
> Thus, although the bio setup as done by __blkdev_issue_write_same() from
> commit e73c23ff736e ("block: add async variant of blkdev_issue_zeroout")
> would succeed, its actual submission would not, resulting in the
> EOPNOTSUPP == 95.
>
> Fix this by removing the fallthrough which, due to the lack of an explicit
> comment, seems to be unintended anyway.
>
> Fixes: e73c23ff736e ("block: add async variant of blkdev_issue_zeroout")
> Fixes: 2d253440b5af ("block: Define zoned block device operations")
> Signed-off-by: Nicolai Stange
Added, thanks.
--
Jens Axboe
usb/gadget: warning in dummy_free_request
Hi! I've got the following error report while running the syzkaller fuzzer. On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2). WARNING: CPU: 0 PID: 5257 at drivers/usb/gadget/udc/dummy_hcd.c:672 dummy_free_request+0x153/0x170 Kernel panic - not syncing: panic_on_warn set ... usb 2-1: string descriptor 0 read error: -71 usb 2-1: New USB device found, idVendor=, idProduct= usb 2-1: New USB device strings: Mfr=0, Product=170, SerialNumber=0 CPU: 0 PID: 5257 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 88006af0ec48 81f96aba 0200 11000d5e1d1c ed000d5e1d14 0a06 41b58ab3 8598b4c8 81f96828 41b58ab3 85942a10 81432790 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x292/0x398 lib/dump_stack.c:51 [] panic+0x1cb/0x3a9 kernel/panic.c:179 [] __warn+0x1c4/0x1e0 kernel/panic.c:542 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:585 [] dummy_free_request+0x153/0x170 drivers/usb/gadget/udc/dummy_hcd.c:672 [] usb_ep_free_request+0xc0/0x420 drivers/usb/gadget/udc/core.c:195 [] gadgetfs_unbind+0x131/0x190 drivers/usb/gadget/legacy/inode.c:1612 [] usb_gadget_remove_driver+0x10f/0x2b0 drivers/usb/gadget/udc/core.c:1228 [] usb_gadget_unregister_driver+0x1b6/0x2c0 drivers/usb/gadget/udc/core.c:1357 [] dev_release+0x80/0x160 drivers/usb/gadget/legacy/inode.c:1187 [] __fput+0x332/0x7f0 fs/file_table.c:208 [] fput+0x15/0x20 fs/file_table.c:244 [] task_work_run+0x19b/0x270 kernel/task_work.c:116 [< inline >] exit_task_work include/linux/task_work.h:21 [] do_exit+0x16aa/0x2530 kernel/exit.c:828 [] do_group_exit+0x149/0x420 kernel/exit.c:932 [] get_signal+0x76d/0x17b0 kernel/signal.c:2307 [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807 [] exit_to_usermode_loop+0x170/0x200 arch/x86/entry/common.c:156 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [] syscall_return_slowpath+0x3d3/0x420 arch/x86/entry/common.c:259 [] entry_SYSCALL_64_fastpath+0xc0/0xc2 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled
[PATCH v2.4 2/3] watchdog: loongson1: Add Loongson1 SoC watchdog driver
Add watchdog timer specific driver for Loongson1 SoC.
Signed-off-by: Yang Ling
---
V2.4:
Set DEFAULT_HEARTBEAT to 0.
V2.3:
Set DEFAULT_HEARTBEAT value to ls1x_wdt->timeout.
V2.2:
Remove the wide character.
Check the return value for clk_get_rate().
V2.1 from Kelvin Cheung:
Use max_hw_heartbeat_ms instead of max_timeout.
V2.0:
Increase the value of the default heartbeat.
Modify the setup process for register.
Order include files and Makefile alphabetically.
V1.1:
Add a little debugging information.
---
drivers/watchdog/Kconfig | 7 ++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/loongson1_wdt.c | 170 +++
3 files changed, 178 insertions(+)
create mode 100644 drivers/watchdog/loongson1_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index fdd3228..c5b9c6e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1513,6 +1513,13 @@ config LANTIQ_WDT
help
Hardware driver for the Lantiq SoC Watchdog Timer.
+config LOONGSON1_WDT
+ tristate "Loongson1 SoC hardware watchdog"
+ depends on MACH_LOONGSON32
+ select WATCHDOG_CORE
+ help
+ Hardware driver for the Loongson1 SoC Watchdog Timer.
+
config RALINK_WDT
tristate "Ralink SoC watchdog"
select WATCHDOG_CORE
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index caa9f4a..0c3d35e 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -163,6 +163,7 @@ obj-$(CONFIG_TXX9_WDT) += txx9wdt.o
obj-$(CONFIG_OCTEON_WDT) += octeon-wdt.o
octeon-wdt-y := octeon-wdt-main.o octeon-wdt-nmi.o
obj-$(CONFIG_LANTIQ_WDT) += lantiq_wdt.o
+obj-$(CONFIG_LOONGSON1_WDT) += loongson1_wdt.o
obj-$(CONFIG_RALINK_WDT) += rt2880_wdt.o
obj-$(CONFIG_IMGPDC_WDT) += imgpdc_wdt.o
obj-$(CONFIG_MT7621_WDT) += mt7621_wdt.o
diff --git a/drivers/watchdog/loongson1_wdt.c b/drivers/watchdog/loongson1_wdt.c
new file mode 100644
index 000..1c75bda
--- /dev/null
+++ b/drivers/watchdog/loongson1_wdt.c
@@ -0,0 +1,170 @@
+/*
+ * Copyright (c) 2016 Yang Ling
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define DEFAULT_HEARTBEAT 0
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0444);
+
+static unsigned int heartbeat = DEFAULT_HEARTBEAT;
+module_param(heartbeat, uint, 0444);
+
+struct ls1x_wdt_drvdata {
+ void __iomem *base;
+ struct clk *clk;
+ unsigned long clk_rate;
+ struct watchdog_device wdt;
+};
+
+static int ls1x_wdt_ping(struct watchdog_device *wdt_dev)
+{
+ struct ls1x_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
+
+ writel(0x1, drvdata->base + WDT_SET);
+
+ return 0;
+}
+
+static int ls1x_wdt_set_timeout(struct watchdog_device *wdt_dev,
+ unsigned int timeout)
+{
+ struct ls1x_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
+ unsigned int max_hw_heartbeat = wdt_dev->max_hw_heartbeat_ms / 1000;
+ unsigned int counts;
+
+ wdt_dev->timeout = timeout;
+
+ counts = drvdata->clk_rate * min(timeout, max_hw_heartbeat);
+ writel(counts, drvdata->base + WDT_TIMER);
+
+ return 0;
+}
+
+static int ls1x_wdt_start(struct watchdog_device *wdt_dev)
+{
+ struct ls1x_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
+
+ writel(0x1, drvdata->base + WDT_EN);
+
+ return 0;
+}
+
+static int ls1x_wdt_stop(struct watchdog_device *wdt_dev)
+{
+ struct ls1x_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
+
+ writel(0x0, drvdata->base + WDT_EN);
+
+ return 0;
+}
+
+static const struct watchdog_info ls1x_wdt_info = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+ .identity = "Loongson1 Watchdog",
+};
+
+static const struct watchdog_ops ls1x_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = ls1x_wdt_start,
+ .stop = ls1x_wdt_stop,
+ .ping = ls1x_wdt_ping,
+ .set_timeout = ls1x_wdt_set_timeout,
+};
+
+static int ls1x_wdt_probe(struct platform_device *pdev)
+{
+ struct ls1x_wdt_drvdata *drvdata;
+ struct watchdog_device *ls1x_wdt;
+ unsigned long clk_rate;
+ struct resource *res;
+ int err;
+
+ drvdata = devm_kzalloc(&pdev->dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ drvdata->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(drvdata->base))
+ return PTR_ERR(drvdata->base);
+
+ drvdata->clk = devm_clk_get(&pdev->dev, pdev->name);
+ if (IS_ERR(drvdata->clk))
+
Re: [PATCH 08/10] media: camss: Add files which handle the video device nodes
On 12/05/2016 03:45 PM, Laurent Pinchart wrote:
> Hello,
>
> On Monday 05 Dec 2016 14:44:55 Hans Verkuil wrote:
>> On 11/25/2016 03:57 PM, Todor Tomov wrote:
>>> These files handle the video device nodes of the camss driver.
>>>
>>> Signed-off-by: Todor Tomov
>>> ---
>>>
>>> drivers/media/platform/qcom/camss-8x16/video.c | 597
>>> drivers/media/platform/qcom/camss-8x16/video.h | 67 +++
>>> 2 files changed, 664 insertions(+)
>>> create mode 100644 drivers/media/platform/qcom/camss-8x16/video.c
>>> create mode 100644 drivers/media/platform/qcom/camss-8x16/video.h
>
> [snip]
>
>>> +int msm_video_register(struct camss_video *video, struct v4l2_device
>>> *v4l2_dev,
>>> +const char *name)
>>> +{
>>> + struct media_pad *pad = &video->pad;
>>> + struct video_device *vdev;
>>> + struct vb2_queue *q;
>>> + int ret;
>>> +
>>> + vdev = video_device_alloc();
>>> + if (vdev == NULL) {
>>> + dev_err(v4l2_dev->dev, "Failed to allocate video device\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + video->vdev = vdev;
>>> +
>>> + q = &video->vb2_q;
>>> + q->drv_priv = video;
>>> + q->mem_ops = &vb2_dma_contig_memops;
>>> + q->ops = &msm_video_vb2_q_ops;
>>> + q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>> + q->io_modes = VB2_MMAP;
>>
>> Add modes VB2_DMABUF and VB2_READ. These are for free, so why not?
>> Especially DMABUF is of course very desirable to have.
>
> I certainly agree with VB2_DMABUF, but I wouldn't expose VB2_READ. read() for
> this kind of device is inefficient and we should encourage userspace
> application to move away from it (and certainly make it very clear that new
> applications should not use read() with this device).
VB2_READ is very nice when debugging (no need to program a stream I/O
application first)
and useful when you want to pipe the video.
Nobody uses read() in 'regular' applications since it is obviously inefficient,
but
I don't see that as a reason not to offer VB2_READ.
I don't think this is something anyone will ever abuse, and it is a nice feature
to have (and for free as well).
Regards,
Hans
Re: [PATCH 1/4] rtc: mcp795: fix invalid month setting.
Hi,
On 05/12/2016 at 14:11:50 +0100, Emil Bartczak wrote :
> The 10 month register was always set to value 0 in the RTC hardware.
> Due to the bug month November or December became February.
All your patches are missing your SoB, see Developer's Certificate of
Origin 1.1 in Documentation/SubmittingPatches
> ---
> drivers/rtc/rtc-mcp795.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-mcp795.c b/drivers/rtc/rtc-mcp795.c
> index 4021fd0..266328b 100644
> --- a/drivers/rtc/rtc-mcp795.c
> +++ b/drivers/rtc/rtc-mcp795.c
> @@ -29,7 +29,7 @@
> #define MCP795_EEWREN0x06
> #define MCP795_SRREAD0x05
> #define MCP795_SRWRITE 0x01
> -#define MCP795_READ 0x13
> +#define MCP795_READ 0x13
Unrelated change
> #define MCP795_WRITE 0x12
> #define MCP795_UNLOCK0x14
> #define MCP795_IDWRITE 0x32
> @@ -39,6 +39,7 @@
>
> #define MCP795_ST_BIT0x80
> #define MCP795_24_BIT0x40
> +#define MCP795_LP_BIT0x20
>
> static int mcp795_rtcc_read(struct device *dev, u8 addr, u8 *buf, u8 count)
> {
> @@ -108,7 +109,8 @@ static int mcp795_set_time(struct device *dev, struct
> rtc_time *tim)
> data[1] = (data[1] & 0x80) | ((tim->tm_min / 10) << 4) | (tim->tm_min %
> 10);
> data[2] = ((tim->tm_hour / 10) << 4) | (tim->tm_hour % 10);
> data[4] = ((tim->tm_mday / 10) << 4) | ((tim->tm_mday) % 10);
> - data[5] = (data[5] & 0x10) | (tim->tm_mon / 10) | (tim->tm_mon % 10);
> + data[5] = (data[5] & MCP795_LP_BIT) |
You changed 0x10 in MCP795_LP_BIT which you defined as 0x20, is that
right?
This is also an unrelated change.
> + ((tim->tm_mon / 10) << 4) | (tim->tm_mon % 10);
>
> if (tim->tm_year > 100)
> tim->tm_year -= 100;
> @@ -137,11 +139,11 @@ static int mcp795_read_time(struct device *dev, struct
> rtc_time *tim)
> if (ret)
> return ret;
>
> - tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] &
> 0x0f);
> - tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] &
> 0x0f);
> + tim->tm_sec = ((data[0] & 0x70) >> 4) * 10 + (data[0] & 0x0f);
> + tim->tm_min = ((data[1] & 0x70) >> 4) * 10 + (data[1] & 0x0f);
> tim->tm_hour= ((data[2] & 0x30) >> 4) * 10 + (data[2] & 0x0f);
> tim->tm_mday= ((data[4] & 0x30) >> 4) * 10 + (data[4] & 0x0f);
> - tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] &
> 0x0f);
> + tim->tm_mon = ((data[5] & 0x10) >> 4) * 10 + (data[5] & 0x0f);
All those whitespace changes are actually confusing. Please do them in a
separate patch or in your last patch.
> tim->tm_year= ((data[6] & 0xf0) >> 4) * 10 + (data[6] & 0x0f) +
> 100; /* Assume we are in 20xx */
>
> dev_dbg(dev, "Read from mcp795: %04d-%02d-%02d %02d:%02d:%02d\n",
> --
> 2.7.4
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: [PATCH 09/18] arm64: introduce binfmt_elf32.c
On Fri, Oct 21, 2016 at 11:33:08PM +0300, Yury Norov wrote:
> As we support more than one compat formats, it looks more reasonable
> to not use fs/compat_binfmt.c. Custom binfmt_elf32.c allows to move aarch32
> specific definitions there and make code more maintainable and readable.
Can you remind me why we need this patch (rather than using the default
fs/compat_binfmt_elf.c which you include here anyway)?
> --- /dev/null
> +++ b/arch/arm64/kernel/binfmt_elf32.c
> @@ -0,0 +1,31 @@
> +/*
> + * Support for AArch32 Linux ELF binaries.
> + */
> +
> +/* AArch32 EABI. */
> +#define EF_ARM_EABI_MASK 0xff00
> +
> +#define compat_start_thread compat_start_thread
> +#define COMPAT_SET_PERSONALITY(ex) \
> +do { \
> + clear_thread_flag(TIF_32BIT_AARCH64); \
> + set_thread_flag(TIF_32BIT); \
> +} while (0)
You introduce this here but it seems to still be present in asm/elf.h.
--
Catalin
[PATCH] platform: Introduce button support for the Surface 3
The Surface 3 is not following the ACPI spec for PNP0C40, but nearly.
The device is connected to a I2C device that might have some magic
but we don't know about.
Just create the device after the enumeration and use the declared GPIOs
to provide button support.
This driver is just an adaptation of drivers/input/misc/soc_button_array.c
The Surface Pro 3 is using an ACPI driver and matches against the bid
of the device ("VGBI"). To prevent this incompatible driver to be used
on the Surface Pro, we add a match on the Surface 3 bid "TEV2".
link: https://bugzilla.kernel.org/show_bug.cgi?id=102761
Signed-off-by: Benjamin Tissoires
---
Hi,
This driver is not in input/misc because I'd prefer keeping it closer
to the surfacepro3_button, which is already in platform/x86.
The Surface Pro 3 and non-Pro 3 both share the same PNPId for the button device
with completely different way of handling those :/
Cheers,
Benjamin
---
drivers/platform/x86/Kconfig | 6 +
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/surface3_button.c | 250 +
3 files changed, 257 insertions(+)
create mode 100644 drivers/platform/x86/surface3_button.c
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 152aac6..7bf3924 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1023,6 +1023,12 @@ config SURFACE_PRO3_BUTTON
---help---
This driver handles the power/home/volume buttons on the Microsoft
Surface Pro 3/4 tablet.
+config SURFACE_3_BUTTON
+ tristate "Power/home/volume buttons driver for Microsoft Surface 3
tablet"
+ depends on ACPI && KEYBOARD_GPIO
+ ---help---
+ This driver handles the power/home/volume buttons on the Microsoft
Surface 3 tablet.
+
config INTEL_PUNIT_IPC
tristate "Intel P-Unit IPC Driver"
---help---
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 38f5419..12c1482 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PVPANIC) += pvpanic.o
obj-$(CONFIG_ALIENWARE_WMI)+= alienware-wmi.o
obj-$(CONFIG_INTEL_PMC_IPC)+= intel_pmc_ipc.o
obj-$(CONFIG_SURFACE_PRO3_BUTTON) += surfacepro3_button.o
+obj-$(CONFIG_SURFACE_3_BUTTON) += surface3_button.o
obj-$(CONFIG_INTEL_PUNIT_IPC) += intel_punit_ipc.o
obj-$(CONFIG_INTEL_TELEMETRY) += intel_telemetry_core.o \
intel_telemetry_pltdrv.o \
diff --git a/drivers/platform/x86/surface3_button.c
b/drivers/platform/x86/surface3_button.c
new file mode 100644
index 000..8bfd7f6
--- /dev/null
+++ b/drivers/platform/x86/surface3_button.c
@@ -0,0 +1,250 @@
+/*
+ * Supports for the button array on the Surface tablets.
+ *
+ * (C) Copyright 2016 Red Hat, Inc
+ *
+ * Based on soc_button_array.c:
+ *
+ * {C} Copyright 2014 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define SURFACE_BUTTON_OBJ_NAME"TEV2"
+#define MAX_NBUTTONS 4
+
+/*
+ * Some of the buttons like volume up/down are auto repeat, while others
+ * are not. To support both, we register two platform devices, and put
+ * buttons into them based on whether the key should be auto repeat.
+ */
+#define BUTTON_TYPES 2
+
+/*
+ * Power button, Home button, Volume buttons support is supposed to
+ * be covered by drivers/input/misc/soc_button_array.c, which is implemented
+ * according to "Windows ACPI Design Guide for SoC Platforms".
+ * However surface 3 seems not to obey the specs, instead it uses
+ * device TEV2(MSHW0028) for declaring the GPIOs. The gpios are also slightly
+ * different in which the Home button is active high.
+ * Compared to surfacepro3_button.c which also handles MSHW0028, the Surface 3
+ * is a reduce platform and thus uses GPIOs, not ACPI events.
+ * We choose an I2C driver here because we need to access the resources
+ * declared under the device node, while surfacepro3_button.c only needs
+ * the ACPI companion node.
+ */
+static const struct acpi_device_id surface3_acpi_match[] = {
+ { "MSHW0028", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, surface3_acpi_match);
+
+struct surface3_button_info {
+ const char *name;
+ int acpi_index;
+ unsigned int event_type;
+ unsigned int event_code;
+ bool autorepeat;
+ bool wakeup;
+ bool active_low;
+};
+
+struct surface3_button_data {
+ struct platform_device *children[BUTTON_TYPES];
+};
+
+/*
+ * Get the Nth GPIO number from the ACPI object.
+ */
+static int surface3_button_lookup_gpio(struct device *dev, int acpi_index)
+
Re: scsi: use-after-free in bio_copy_from_iter
On Mon, Dec 05, 2016 at 03:31:43PM +0100, Dmitry Vyukov wrote:
> On Sat, Dec 3, 2016 at 7:19 PM, Johannes Thumshirn wrote:
> > On Sat, Dec 03, 2016 at 04:22:39PM +0100, Dmitry Vyukov wrote:
> >> On Sat, Dec 3, 2016 at 11:38 AM, Johannes Thumshirn
> >> wrote:
> >> > On Fri, Dec 02, 2016 at 05:50:39PM +0100, Dmitry Vyukov wrote:
> >> >> On Fri, Nov 25, 2016 at 8:08 PM, Dmitry Vyukov
> >> >> wrote:
> >
> > [...]
> >
> > Hi Dmitry,
> >
> >>
> >> Thanks for looking into this!
> >>
> >> As I noted I don't think this is use-after-free, more likely it is an
> >> out-of-bounds access against non-slab range.
> >>
> >> Report says that we are copying 0x1000 bytes starting at
> >> 0x880062c6e02a.
> >> The first bad address is 0x880062c6f000, this address was freed
> >> previously and that's why KASAN reports UAF.
> >
> > We're copying 65499 bytes (65535 - sizeof(sg_header)) and we've got 2 order
> > 3
> > page allocations to do this. It fails somewhere in there. I have seen fails
> > at
> > 0x2000, 0xe000 and all (0x1000 aligned) offsets inbetween.
> >
> >> But this is already next page, and KASAN does not insert redzones
> >> around pages (only around slab allocations).
> >> So most likely the code should have not touch 0x880062c6f000 as it
> >> is not his memory.
> >> Also I noticed that the report happens after few minutes of repeatedly
> >> running this program, so I would expect that this is some kind of race
> >> -- either between kernel threads, or maybe between user space threads
> >> and kernel.
> >
> > I somehow think it's a race as well, especially as I have to run the
> > reproducer in an endless loop and break out of it once I have the 1st
> > stacktrace in dmesg. This takes between some minutes up to one hour on my
> > setup.
> >
> > But the race against a userspace thread... Could it be that the reproducer
> > has
> > already exited it's threads while the copy_from_iter() is still running?
> > Normally I'd say no, as user-space shouldn't run while the kernel is doing
> > things in it's address space, but this is highly suspicious.
> >
> >> Or maybe it's just that the next page is not always marked
> >> as free, so we just don't detect the bad access.
> >
> > Could be, but I lack the memory management knowledge to say more than a
> > 'could
> > be'.
> >
> >>
> >> Does it all make any sense to you?
> >> Can you think of any additional sanity checks that will ensure that
> >> this code copies only memory it owns?
> >
> > Given that we pass the 0x as dxfer_len it thinks it owns all memory, so
> > this is OK, kinda. All that could be would be that user-space has already
> > exited and thus it's memory is already freed.
>
>
> The crash happens in the context of sendfile syscall, we the address
> space should be alive. But the crash happens on address
> 0x880062c6f000 which is not a user-space address, right? This is
> something that kernel has allocated previously.
> Do you have CONFIG_DEBUG_PAGEALLOC enabled? I have it enabled. Maybe
> it increases changes of triggering the bug.
>
> Do we know where that memory that we are copying was allocated? Is it
> slab or page alloc? We could extend KASAN output with more details.
> E.g. print allocation stack for the _first_ byte of memcpy, or
> memorize page alloc/free stacks in page struct using lib/stackdepot.c.
It comes in this way:
drivers/scsi/sg.c:
sg_write(struct file *filp, const char __user *buf, size_t count, loff_t * ppos)
580 struct sg_header old_hdr;
581 sg_io_hdr_t *hp;
582 unsigned char cmnd[SG_MAX_CDB_SIZE];
[...]
598 if (__copy_from_user(&old_hdr, buf, SZ_SG_HEADER))
599 return -EFAULT;
[...]
612 buf += SZ_SG_HEADER;
613 __get_user(opcode, buf);
[...]
614 if (sfp->next_cmd_len > 0) {
615 cmd_size = sfp->next_cmd_len;
616 sfp->next_cmd_len = 0; /* reset so only this write()
effected */
617 } else {
618 cmd_size = COMMAND_SIZE(opcode);/* based on SCSI
command group */
619 if ((opcode >= 0xc0) && old_hdr.twelve_byte)
620 cmd_size = 12;
621 }
[...]
625 input_size = count - cmd_size;
626 mxsize = (input_size > old_hdr.reply_len) ? input_size :
old_hdr.reply_len;
627 mxsize -= SZ_SG_HEADER;
633 hp = &srp->header;
[...]
646 hp->dxferp = (char __user *)buf + cmd_size;
[...]
654 if (__copy_from_user(cmnd, buf, cmd_size))
655 return -EFAULT;
[...]
675 k = sg_common_write(sfp, srp, cmnd, sfp->timeout, blocking);
[...]
752 static int
753 sg_common_write(Sg_fd * sfp, Sg_request * srp,
754 unsigned char *cmnd, int timeout, int blocking)
755 {
[...]
772 k = sg_start_req(srp, cmnd);
[...]
1653 static int
1654 sg_start_req(Sg_request *srp, unsigned char *cmd)
1655 {
[...]
1757 res = blk_rq_map_user(q, rq, md, hp->dxferp,
1758
Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir
On Mon, Dec 05, 2016 at 10:28:18AM +0100, Miklos Szeredi wrote: > [Added a few more CCs] > > On Mon, Dec 5, 2016 at 1:51 AM, Patrick Plagwitz > wrote: > > Mounting an overlayfs with an NFSv4 lowerdir and an ext4 upperdir causes > > copy_up operations, specifically the function copy_up.c:ovl_copy_xattr, to > > fail with EOPNOTSUPP. > > For example, having the following folders: > > > > |- nfs <- NFSv4 is mounted here > > |--|- folder > > |- root <- ext4 is mounted here > > |- work <- also ext4 > > |- merged <- overlay is mounted here with > > lowerdir=nfs,upperdir=root,workdir=work > > > > And calling > > # touch merged/folder/file > > will print > > touch: cannot touch 'merged/folder/file': Operation not supported > > > > This is because NFS returns the xattr system.nfs4_acl with an empty value > > even if no NFS ACLs are in use in the lower filesystem. Trying to set this > > xattr in the upperdir > > fails because ext4 does not support it. > > > > Fix this by explicitly checking for the name of the xattr and an empty > > value and ignoring EOPNOTSUPP if both things match. > > > > Signed-off-by: Patrick Plagwitz > > --- > > Maybe NFS could be changed to not return empty system.nfs4_acl values, I > > don't know. In any case, to support upperdir ext4 + lowerdir NFSv4, > > returning the error code from > > vfs_setxattr with this xattr name must be avoided as long as the value is > > empty. > > > > diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c > > index 36795ee..505b86e 100644 > > --- a/fs/overlayfs/copy_up.c > > +++ b/fs/overlayfs/copy_up.c > > @@ -123,6 +123,9 @@ int ovl_copy_xattr(struct dentry *old, struct dentry > > *new) > > continue; /* Discard */ > > } > > error = vfs_setxattr(new, name, value, size, 0); > > + if (error == -EOPNOTSUPP && *value == '\0' && > > + strcmp(name, "system.nfs4_acl") == 0) > > + error = 0; > > if (error) > > break; > > } > > I agree that this should be fixed, but adding such exceptions for > certain filesystems or xattrs is not the proper way, IMO. > > Can NFS people comment on this? Where does the nfs4_acl come from? This is the interface the NFS client provides for applications to modify NFSv4 ACLs on servers that support them. > What can overlayfs do if it's a non-empty ACL? As little as possible. You can't copy it up, can you? So any attempt to support it is going to be incomplete. > Does knfsd translate posix ACL into NFS acl? If so, we can translate > back. Should we do a generic POSIX<->NFS acl translator? knsd does translate between POSIX and NFSv4 ACLs. It's a complicated algorithm, and lossy (in the NFSv4->POSIX direction). The client developers have been understandably reluctant to have anything to do with it. So, I think listxattr should omit system.nfs4_acl, and attempts to set/get the attribute should error out. The same should apply to any "system." attribute not supported by both filesystems, I think? I don't understand overlayfs very well, though. --b.
Re: [PATCH 08/10] media: camss: Add files which handle the video device nodes
Hi Todor,
Thank you for the patch.
On Friday 25 Nov 2016 16:57:20 Todor Tomov wrote:
> These files handle the video device nodes of the camss driver.
camss is a quite generic, I'm a bit concerned about claiming that acronym in
the global kernel namespace. Would it be too long if we prefixed symbols with
msm_camss instead ?
> Signed-off-by: Todor Tomov
> ---
> drivers/media/platform/qcom/camss-8x16/video.c | 597 ++
> drivers/media/platform/qcom/camss-8x16/video.h | 67 +++
> 2 files changed, 664 insertions(+)
> create mode 100644 drivers/media/platform/qcom/camss-8x16/video.c
> create mode 100644 drivers/media/platform/qcom/camss-8x16/video.h
>
> diff --git a/drivers/media/platform/qcom/camss-8x16/video.c
> b/drivers/media/platform/qcom/camss-8x16/video.c new file mode 100644
> index 000..0bf8ea9
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss-8x16/video.c
> @@ -0,0 +1,597 @@
> +/*
> + * video.c
> + *
> + * Qualcomm MSM Camera Subsystem - V4L2 device node
> + *
> + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
> + * Copyright (C) 2015-2016 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "video.h"
> +#include "camss.h"
> +
> +/*
> + * struct format_info - ISP media bus format information
> + * @code: V4L2 media bus format code
> + * @pixelformat: V4L2 pixel format FCC identifier
> + * @bpp: Bits per pixel when stored in memory
> + */
> +static const struct format_info {
> + u32 code;
> + u32 pixelformat;
> + unsigned int bpp;
> +} formats[] = {
> + { MEDIA_BUS_FMT_UYVY8_2X8, V4L2_PIX_FMT_UYVY, 16 },
> + { MEDIA_BUS_FMT_VYUY8_2X8, V4L2_PIX_FMT_VYUY, 16 },
> + { MEDIA_BUS_FMT_YUYV8_2X8, V4L2_PIX_FMT_YUYV, 16 },
> + { MEDIA_BUS_FMT_YVYU8_2X8, V4L2_PIX_FMT_YVYU, 16 },
> + { MEDIA_BUS_FMT_SBGGR8_1X8, V4L2_PIX_FMT_SBGGR8, 8 },
> + { MEDIA_BUS_FMT_SGBRG8_1X8, V4L2_PIX_FMT_SGBRG8, 8 },
> + { MEDIA_BUS_FMT_SGRBG8_1X8, V4L2_PIX_FMT_SGRBG8, 8 },
> + { MEDIA_BUS_FMT_SRGGB8_1X8, V4L2_PIX_FMT_SRGGB8, 8 },
> + { MEDIA_BUS_FMT_SBGGR10_1X10, V4L2_PIX_FMT_SBGGR10P, 10 },
> + { MEDIA_BUS_FMT_SGBRG10_1X10, V4L2_PIX_FMT_SGBRG10P, 10 },
> + { MEDIA_BUS_FMT_SGRBG10_1X10, V4L2_PIX_FMT_SGRBG10P, 10 },
> + { MEDIA_BUS_FMT_SRGGB10_1X10, V4L2_PIX_FMT_SRGGB10P, 10 },
> + { MEDIA_BUS_FMT_SBGGR12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 },
> + { MEDIA_BUS_FMT_SGBRG12_1X12, V4L2_PIX_FMT_SGBRG12P, 12 },
> + { MEDIA_BUS_FMT_SGRBG12_1X12, V4L2_PIX_FMT_SGRBG12P, 12 },
> + { MEDIA_BUS_FMT_SRGGB12_1X12, V4L2_PIX_FMT_SRGGB12P, 12 }
> +};
> +
> +/*
> ---
> -- + * Helper functions
> + */
> +
> +/*
> + * video_mbus_to_pix - Convert v4l2_mbus_framefmt to v4l2_pix_format
> + * @mbus: v4l2_mbus_framefmt format (input)
> + * @pix: v4l2_pix_format format (output)
> + *
> + * Fill the output pix structure with information from the input mbus
> format.
> + *
> + * Return 0 on success or a negative error code otherwise
> + */
> +static unsigned int video_mbus_to_pix(const struct v4l2_mbus_framefmt
> *mbus,
> + struct v4l2_pix_format *pix)
> +{
> + unsigned int i;
> +
> + memset(pix, 0, sizeof(*pix));
> + pix->width = mbus->width;
> + pix->height = mbus->height;
> +
> + for (i = 0; i < ARRAY_SIZE(formats); ++i) {
> + if (formats[i].code == mbus->code)
> + break;
> + }
> +
> + if (WARN_ON(i == ARRAY_SIZE(formats)))
> + return -EINVAL;
> +
> + pix->pixelformat = formats[i].pixelformat;
> + pix->bytesperline = pix->width * formats[i].bpp / 8;
> + pix->bytesperline = ALIGN(pix->bytesperline, 8);
Does the hardware support padding at the end of lines ? If so it would be
useful to use the maximum of the computed and requested by userspace values
(up to the maximum size of the padding supported by the hardware).
> + pix->sizeimage = pix->bytesperline * pix->height;
Similarly, should we support padding at the end of the image ?
> + pix->colorspace = mbus->colorspace;
> + pix->field = mbus->field;
> +
> + return 0;
> +}
> +
> +static struct v4l2_subdev *video_remote_subdev(struct camss_video *video,
> +u32 *pad)
> +{
> + struct media_pad *remote;
> +
> + remote = media_entity_remote_pad(&video->pad);
> +
> + if (!remo
Re: [PATCH] USB: cdc-acm: add device id for GW Instek AFG-125
On Mon, 2016-12-05 at 06:53 -0800, Nathaniel Quillin wrote: > Add device-id entry for GW Instek AFG-125, which has a byte swapped > bInterfaceSubClass (0x20). > > Signed-off-by: Nathaniel Quillin Acked-by: Oliver Neukum
