Re: [RFT v2] iommu/amd: use subsys_initcall() on amdv2 iommu
On Mon, Apr 18, 2016 at 9:55 AM, Luis R. Rodriguez wrote:
>
> On Apr 18, 2016 7:48 AM, "Oded Gabbay" wrote:
>>
>> On Wed, Apr 13, 2016 at 1:07 AM, Luis R. Rodriguez
>> wrote:
>> > On Mon, Apr 11, 2016 at 03:52:43PM +0200, Christian König wrote:
>> >> Am 11.04.2016 um 15:39 schrieb Oded Gabbay:
>> >> >On Mon, Apr 11, 2016 at 4:28 PM, Christian König
>> >> > wrote:
>> >> >>Am 09.04.2016 um 02:25 schrieb Luis R. Rodriguez:
>> >> >>>On Tue, Mar 29, 2016 at 10:41 AM, Luis R. Rodriguez
>> >> >>> wrote:
>> >> We need to ensure amd iommu v2 initializes before
>> >> driver uses such as drivers/gpu/drm/amd/amdkfd/kfd_module.c,
>> >> to do this make its init routine a subsys_initcall() which
>> >> ensures its load init is called first than modules when
>> >> built-in.
>> >>
>> >> This reverts the old work around implemented through commit
>> >> 1bacc894c227fad8a7 ("drivers: Move iommu/ before gpu/ in
>> >> Makefile"),
>> >> instead of making the dependency implicit by linker order this
>> >> makes the ordering requirement explicit through proper kernel
>> >> APIs.
>> >>
>> >> Cc: Oded Gabbay
>> >> Cc: Christian König
>> >> Signed-off-by: Luis R. Rodriguez
>> >> >>
>> >> >>Sorry for not responding earlier. Just coming back to all the stuff
>> >> >> on my TODO list.
>> >> >>
>> >> >>Patch is Acked-by: Christian König
>> >> >
>> >> >Christian,
>> >> >Just wanted to be sure if you tested this patch-set or not.
>> >>
>> >> I did NOT tested it. If AMD IOMMU requires something which will now
>> >> initialize after the IOMMU module we will obviously run into trouble
>> >> again.
>> >>
>> >> I assumed that the creator of the patch did some testing.
>> >
>> > Nope, hence [RTF] Request For Testing.
>> >
>> >> >I don't think it should be merged without testing. If you already
>> >> >tested it than fine. If not, I think I can do it in the next week or
>> >> >so (just came back from PTO).
>> >>
>> >> Yeah, agree totally.
>> >
>> > Agreed, please let me know if someone is able to test and confirm
>> > this works. It should work.
>> >
>> > Luis
>>
>> Hi,
>> So I finally got to test this patch and it's not working.
>> The reason is that AMD IOMMUv2 gets initialized *before* AMD IOMMUv1
>> driver !
>
> Thanks can you try using late_initcall() instead then?
>
> Luis
That will make it initialize *after* drm subsystem, which will cause
another bug.
Oded
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On Mon, Apr 18, 2016 at 02:02:51PM +0800, Baolin Wang wrote: > > If the crypto hardware engine can support bulk data > encryption/decryption, so the engine driver can select bulk mode to > handle the requests. I think it is a totally driver things, not in > dmcrypt. The dmcrypt can not get the hardware engine's attributes. It has nothing to do with the hardware attributes. dm-crypt should be sending maximal requests in the first place. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RESEND PATCH] drm/panel: simple-panel: set appropriate mode type
On Fri, Apr 15, 2016 at 06:23:33PM +0200, Nicolas Ferre wrote: > From: Boris Brezillon > > All modes exposed by simple panels should be tagged as driver defined > modes. > Moreover, if a panel supports only one mode, this mode is obviously the > preferred one. > > Doing this also fix a problem occurring when a 'video=' parameter is passed > on the kernel cmdline. In some cases the user provided mode is preferred > over the simple panel ones, which might result in unpredictable behavior. > > Signed-off-by: Boris Brezillon > Reviewed-by: Nicolas Ferre > Tested-by: Nicolas Ferre > --- > drivers/gpu/drm/panel/panel-simple.c | 8 > 1 file changed, 8 insertions(+) Applied, thanks. Thierry signature.asc Description: PGP signature
Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
On Tue, Apr 05, 2016 at 05:05:14PM +0300, Roger Quadros wrote:
> The OTG state machine needs a mechanism to start and
> stop the gadget controller. Add usb_gadget_start()
> and usb_gadget_stop().
>
> Introduce usb_otg_add_gadget_udc() to allow controller drivers
> to register a gadget controller that is part of an OTG instance.
>
> Register with OTG core when gadget function driver
> is available and unregister when function driver is unbound.
>
> We need to unlock the usb_lock mutexbefore calling
...mutex before...
> usb_otg_register_gadget() in udc_bind_to_driver() and
> usb_gadget_remove_driver() else it will cause a circular
> locking dependency.
>
> Ignore softconnect sysfs control when we're in OTG
> mode as OTG FSM takes care of gadget softconnect using
> the b_bus_req mechanism.
>
> Signed-off-by: Roger Quadros
> ---
> drivers/usb/gadget/udc/udc-core.c | 166
> +++---
> include/linux/usb/gadget.h| 4 +
> 2 files changed, 161 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/udc-core.c
> b/drivers/usb/gadget/udc/udc-core.c
> index 4151597..9b9702f 100644
> --- a/drivers/usb/gadget/udc/udc-core.c
> +++ b/drivers/usb/gadget/udc/udc-core.c
> @@ -28,6 +28,10 @@
> #include
> #include
> #include
> +#include
> +
> +#include
> +#include
>
> /**
> * struct usb_udc - describes one usb device controller
> @@ -304,6 +308,7 @@ EXPORT_SYMBOL_GPL(usb_gadget_udc_reset);
> */
> static inline int usb_gadget_udc_start(struct usb_udc *udc)
> {
> + dev_dbg(&udc->dev, "%s\n", __func__);
> return udc->gadget->ops->udc_start(udc->gadget, udc->driver);
> }
You may delete the debug message next time.
>
> @@ -321,10 +326,81 @@ static inline int usb_gadget_udc_start(struct usb_udc
> *udc)
> */
> static inline void usb_gadget_udc_stop(struct usb_udc *udc)
> {
> + dev_dbg(&udc->dev, "%s\n", __func__);
> udc->gadget->ops->udc_stop(udc->gadget);
> }
The same.
>
> /**
> + * usb_gadget_start - start the usb gadget controller and connect to bus
> + * @gadget: the gadget device to start
> + *
> + * This is external API for use by OTG core.
> + *
> + * Start the usb device controller and connect to bus (enable pull).
> + */
> +static int usb_gadget_start(struct usb_gadget *gadget)
> +{
> + int ret;
> + struct usb_udc *udc = NULL;
> +
> + dev_dbg(&gadget->dev, "%s\n", __func__);
The same
> + mutex_lock(&udc_lock);
> + list_for_each_entry(udc, &udc_list, list)
> + if (udc->gadget == gadget)
> + goto found;
> +
> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> + __func__);
> + mutex_unlock(&udc_lock);
> + return -EINVAL;
> +
> +found:
> + ret = usb_gadget_udc_start(udc);
> + if (ret)
> + dev_err(&udc->dev, "USB Device Controller didn't start: %d\n",
> + ret);
> + else
> + usb_udc_connect_control(udc);
> +
> + mutex_unlock(&udc_lock);
> +
> + return ret;
> +}
> +
> +/**
> + * usb_gadget_stop - disconnect from bus and stop the usb gadget
> + * @gadget: The gadget device we want to stop
> + *
> + * This is external API for use by OTG core.
> + *
> + * Disconnect from the bus (disable pull) and stop the
> + * gadget controller.
> + */
> +static int usb_gadget_stop(struct usb_gadget *gadget)
> +{
> + struct usb_udc *udc = NULL;
> +
> + dev_dbg(&gadget->dev, "%s\n", __func__);
The same
> + mutex_lock(&udc_lock);
> + list_for_each_entry(udc, &udc_list, list)
> + if (udc->gadget == gadget)
> + goto found;
> +
> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> + __func__);
> + mutex_unlock(&udc_lock);
> + return -EINVAL;
The above finding gadget code is the same with usb_gadget_start, can we
use one common API to instead of it?
> +
> +found:
> + usb_gadget_disconnect(udc->gadget);
> + udc->driver->disconnect(udc->gadget);
> + usb_gadget_udc_stop(udc);
> + mutex_unlock(&udc_lock);
> +
> + return 0;
> +}
> +
> +/**
> * usb_udc_release - release the usb_udc struct
> * @dev: the dev member within usb_udc
> *
> @@ -486,6 +562,48 @@ int usb_add_gadget_udc(struct device *parent, struct
> usb_gadget *gadget)
> }
> EXPORT_SYMBOL_GPL(usb_add_gadget_udc);
>
> +/**
> + * usb_otg_add_gadget_udc - adds a new gadget to the udc class driver list
> + * @parent: the parent device to this udc. Usually the controller
> + * driver's device.
> + * @gadget: the gadget to be added to the list
> + * @otg_dev: the OTG controller device
> + *
> + * If otg_dev is NULL then device tree node is checked
> + * for OTG controller via the otg-controller property.
> + * Returns zero on success, negative errno otherwise.
> + */
> +int usb_otg_add_gadget_udc(struct device *parent, struct usb_gadget *gadget,
> +struct device *otg_dev)
> +{
> + if (!
Re: [PATCH 1/2] char: PC rtc: replace blacklist with whitelist
Hi Arnd,
cc linux-m68k
On Sun, Apr 17, 2016 at 11:37 PM, Arnd Bergmann wrote:
> On Wednesday 02 March 2016 11:22:04 Geert Uytterhoeven wrote:
>> On Wed, Mar 2, 2016 at 10:48 AM, Arnd Bergmann wrote:
>> > Every new architecture has to add itself to the growing list of those
>> > that do not support the legacy PC RTC driver.
>> >
>> > This replaces the long list of architectures that don't support it
>> > with a shorter list of those that do.
>> >
>> > The list is taken from those architectures that have a non-empty
>> > asm/mc146818rtc.h header file and were not explicitly blacklisted.
>>
>> M68K was blacklisted...
>
> I never got back to you on this topic, sorry about that. I've fixed
> up the patch to leave out m68k now.
>
> On a semi-related note, I see that m68k is one of the few architectures
> still using the (other) genrtc driver. It would be nice to reduce that
> list and change m68k to use its own rtc driver (ideally one per
We do have hp_sdc_rtc (HP9000/300; why is that under drivers/input/misc/?),
and rtc-msm6242 and rtc-rp5c01 (both for Amiga).
> platform), but the q40 platform is the only one providing
> get_rtc_pll()/set_rtc_pll() for the RTC_PLL_GET/RTC_PLL_SET ioctl
> commands.
Do you mean this is a problem?
> If we do this change on top of the other m68k patch I have, the
> rtc-generic driver should be usable as a full replacement for
> genrtc.c on m68k and we can remove all the set_rtc_pll/get_rtc_pll
> handling from genrtc.
>
> diff --git a/arch/m68k/kernel/time.c b/arch/m68k/kernel/time.c
> index 773b2187210d..f4781d612c37 100644
> --- a/arch/m68k/kernel/time.c
> +++ b/arch/m68k/kernel/time.c
> @@ -100,7 +100,32 @@ static int rtc_generic_set_time(struct device *dev,
> struct rtc_time *tm)
> return 0;
> }
>
> +static int rtc_ioctl(struct device *dev, unsigned int cmd, unsigned long arg)
> +{
> + struct rtc_pll_info pll;
> + struct rtc_pll_info __user *argp = (void __user *)arg;
> +
> + switch (cmd) {
> + case RTC_PLL_GET:
> + if (!mach_get_rtc_pll || mach_get_rtc_pll(&pll))
> + return -EINVAL;
> + return copy_to_user(argp, &pll, sizeof pll) ? -EFAULT : 0;
> +
> + case RTC_PLL_SET:
> + if (!mach_set_rtc_pll)
> + return -EINVAL;
> + if (!capable(CAP_SYS_TIME))
> + return -EACCES;
> + if (copy_from_user(&pll, argp, sizeof(pll)))
> + return -EFAULT;
> + return mach_set_rtc_pll(&pll);
> + }
> +
> + return -ENOIOCTLCMD;
> +}
> +
> static const struct rtc_class_ops generic_rtc_ops = {
> + .ioctl = rtc_ioctl,
> .read_time = rtc_generic_get_time,
> .set_time = rtc_generic_set_time,
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm: panel: simple-panel: remove useless drm_mode_set_name
On Thu, Apr 30, 2015 at 04:38:36PM +0200, Boris Brezillon wrote: > drm_display_mode_from_videomode() is already calling drm_mode_set_name() on > the provided mode. > > Signed-off-by: Boris Brezillon > --- > drivers/gpu/drm/panel/panel-simple.c | 1 - > 1 file changed, 1 deletion(-) Applied, with a slightly reworded commit message. Thierry signature.asc Description: PGP signature
Re: [LKP] [lkp] [parallel lookups machinery, part 2] 96352435af: kernel BUG at mm/slab.c:2599!
Al Viro writes: Hi, Viro, > On Mon, Apr 18, 2016 at 10:08:37AM +0800, Huang, Ying wrote: > >> Could you provide a debug branch in your tree for that? > > Done - vfs.git#T1 and vfs.git#T2 resp. The compare result between T1 and T2 is as follow: = compiler/kconfig/rootfs/sleep/tbox_group/testcase: gcc-5/x86_64-allyesdebian/quantal-core-x86_64.cgz/1/vm-vp-quantal-x86_64/boot commit: 3ab6378a68555a90a11360e2f2d63c9adb4e7101 (T1) e570d87b645a0bfd80e36df9753faf3598c9fce0 (T2) 3ab6378a68555a90 e570d87b645a0bfd80e36df975 -- fail:runs %reproductionfail:runs | | | 47:47-100%:3 dmesg.Kernel_panic-not_syncing:Fatal_exception_in_interrupt 47:47-100%:3 dmesg.RIP:kfree_debugcheck 47:47-100%:3 dmesg.invalid_opcode:#[##]SMP 47:47-100%:3 dmesg.kernel_BUG_at_mm/slab.c 7:47 -15%:3 kmsg.APIC_calibration_not_consistent_with_PM-Timer:#ms_instead_of#ms 1:47 -2%:3 kmsg.kfree_debugcheck:out_of_range_ptr#a8h 7:47 -15%:3 kmsg.kfree_debugcheck:out_of_range_ptr#aah 21:47 -45%:3 kmsg.kfree_debugcheck:out_of_range_ptr#ach 1:47 -2%:3 kmsg.kfree_debugcheck:out_of_range_ptr#bah 2:47 -4%:3 kmsg.kfree_debugcheck:out_of_range_ptr#ch 4:47 -9%:3 kmsg.kfree_debugcheck:out_of_range_ptr#eh 11:47 -23%:3 kmsg.kfree_debugcheck:out_of_range_ptr#h That is, there is same issue for T1, but no such issue for T2. > How reproducible it is and how certain you are that it's not there on > the parent commit? The result is quite stable for tens tests for parents and the first bad commit. Best Regards, Huang, Ying
[PATCH] mmc: mediatek: fix request blocked by cancel_delayed_work
there are 2 points will cause could not call mmc_request_done()
and eventually cause the caller thread blocked.
A. if card was busy, cancel_delayed_work() will return false because
the delay work has not been scheduled, in this case, need put
mod_delayed_work() in front of msdc_cmd_is_ready()
B. if a request really need more than 5s(Some Sandisk TF card), it will
use cancel_delayed_work() to cancel itself, and also return false, so use
in_interrupt() to avoid this case
Signed-off-by: Chaotian Jing
---
drivers/mmc/host/mtk-sd.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index b17f30d..1511b1b 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -724,7 +724,7 @@ static void msdc_request_done(struct msdc_host *host,
struct mmc_request *mrq)
bool ret;
ret = cancel_delayed_work(&host->req_timeout);
- if (!ret) {
+ if (!ret && in_interrupt()) {
/* delay work already running */
return;
}
@@ -824,7 +824,12 @@ static inline bool msdc_cmd_is_ready(struct msdc_host
*host,
}
if (mmc_resp_type(cmd) == MMC_RSP_R1B || cmd->data) {
- tmo = jiffies + msecs_to_jiffies(20);
+ /*
+* 2550ms is from EXT_CSD[248], after switch to hs200,
+* using CMD13 to polling card status, it will get response
+* of 0x800, but EMMC still pull-low DAT0.
+*/
+ tmo = jiffies + msecs_to_jiffies(2550);
/* R1B or with data, should check SDCBUSY */
while ((readl(host->base + SDC_STS) & SDC_STS_SDCBUSY) &&
time_before(jiffies, tmo))
@@ -847,6 +852,7 @@ static void msdc_start_command(struct msdc_host *host,
WARN_ON(host->cmd);
host->cmd = cmd;
+ mod_delayed_work(system_wq, &host->req_timeout, DAT_TIMEOUT);
if (!msdc_cmd_is_ready(host, mrq, cmd))
return;
@@ -858,7 +864,6 @@ static void msdc_start_command(struct msdc_host *host,
cmd->error = 0;
rawcmd = msdc_cmd_prepare_raw_cmd(host, mrq, cmd);
- mod_delayed_work(system_wq, &host->req_timeout, DAT_TIMEOUT);
sdr_set_bits(host->base + MSDC_INTEN, cmd_ints_mask);
writel(cmd->arg, host->base + SDC_ARG);
--
1.8.1.1.dirty
Re: [PATCH] thermal: tegra: mark PM functions __maybe_unused
On Sat, Apr 16, 2016 at 10:19:33PM +0200, Arnd Bergmann wrote:
> After the PM support has been added to this driver, we get
> a harmless warning when that support is disabled at compile
> time:
>
> drivers/thermal/tegra/soctherm.c:641:12: error: 'soctherm_resume' defined but
> not used [-Werror=unused-function]
> static int soctherm_resume(struct device *dev)
>
> This marks the two PM functions as __maybe_unused to shut up
> the warning. This is preferred over adding an #ifdef around
> them, as it is harder to get wrong, and provides better
> compile-time coverage.
>
> Signed-off-by: Arnd Bergmann
> Fixes: a134b4143b65 ("thermal: tegra: add PM support")
> ---
> drivers/thermal/tegra/soctherm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
The need for this should go away when Jon's generic power domain series
gets merged (hopefully very soon now) and enabled on 32-bit ARM. In the
meantime:
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
Re: [PATCH v6 11/12] usb: core: hub: Notify OTG fsm when A device sets b_hnp_enable
On Tue, Apr 05, 2016 at 05:05:16PM +0300, Roger Quadros wrote:
> This is the a_set_b_hnp_enable flag in the OTG state machine
> diagram and must be set when the A-Host has successfully set
> the b_hnp_enable feature of the OTG-B-Peripheral attached to it.
>
> When this bit changes we kick our OTG FSM to make note of the
> change and act accordingly.
Since we have still not added fsm.a_set_b_hnp_en in OTG FSM, and this
patch set is mainly for DRD, would you please move out this patch from
this set?
Peter
>
> Signed-off-by: Roger Quadros
> ---
> drivers/usb/core/hub.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 38cc4ba..27e3b4c 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -2273,6 +2273,7 @@ static int usb_enumerate_device_otg(struct usb_device
> *udev)
> && udev->parent == udev->bus->root_hub) {
> struct usb_otg_descriptor *desc = NULL;
> struct usb_bus *bus = udev->bus;
> + struct usb_hcd *hcd = bus_to_hcd(bus);
> unsignedport1 = udev->portnum;
>
> /* descriptor may appear anywhere in config */
> @@ -2302,6 +2303,9 @@ static int usb_enumerate_device_otg(struct usb_device
> *udev)
> dev_err(&udev->dev, "can't set HNP mode: %d\n",
> err);
> bus->b_hnp_enable = 0;
> + } else {
> + /* notify OTG fsm about a_set_b_hnp_enable */
> + usb_otg_kick_fsm(hcd->otg_dev);
> }
> } else if (desc->bLength == sizeof
> (struct usb_otg_descriptor)) {
> @@ -2312,10 +2316,14 @@ static int usb_enumerate_device_otg(struct usb_device
> *udev)
> USB_DEVICE_A_ALT_HNP_SUPPORT,
> 0, NULL, 0,
> USB_CTRL_SET_TIMEOUT);
> - if (err < 0)
> + if (err < 0) {
> dev_err(&udev->dev,
> "set a_alt_hnp_support failed: %d\n",
> err);
> + } else {
> + /* notify OTG fsm about a_set_b_hnp_enable */
> + usb_otg_kick_fsm(hcd->otg_dev);
> + }
> }
> }
> #endif
> @@ -4355,8 +4363,13 @@ hub_port_init(struct usb_hub *hub, struct usb_device
> *udev, int port1,
>*/
> if (!hdev->parent) {
> delay = HUB_ROOT_RESET_TIME;
> - if (port1 == hdev->bus->otg_port)
> + if (port1 == hdev->bus->otg_port) {
> hdev->bus->b_hnp_enable = 0;
> +#ifdef CONFIG_USB_OTG
> + /* notify OTG fsm about a_set_b_hnp_enable change */
> + usb_otg_kick_fsm(hcd->otg_dev);
> +#endif
> + }
> }
>
> /* Some low speed devices have problems with the quick delay, so */
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On 18 April 2016 at 15:04, Herbert Xu wrote: > On Mon, Apr 18, 2016 at 02:02:51PM +0800, Baolin Wang wrote: >> >> If the crypto hardware engine can support bulk data >> encryption/decryption, so the engine driver can select bulk mode to >> handle the requests. I think it is a totally driver things, not in >> dmcrypt. The dmcrypt can not get the hardware engine's attributes. > > It has nothing to do with the hardware attributes. dm-crypt should > be sending maximal requests in the first place. I don't think so, the dm-crypt can not send maximal requests at some situations. For example, the 'cbc(aes)' cipher, it must be handled sector by sector (IV is dependency for each sector), so the dm-crypt can not send maximal requests, but must sector by sector in this situation. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Baolin.wang Best Regards
Re: [PATCH net-next 2/2] bpf: add event output helper for notifications/sampling/logging
On 04/18/2016 01:55 AM, kbuild test robot wrote:
Hi Daniel,
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Daniel-Borkmann/bpf-trace-add-BPF_F_CURRENT_CPU-flag-for-bpf_perf_event_output/20160418-063147
config: m68k-allyesconfig (attached as .config)
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=m68k
All errors (new ones prefixed by >>):
net/core/filter.c: In function 'bpf_skb_event_output':
net/core/filter.c:1599:2: error: implicit declaration of function
'perf_fetch_caller_regs' [-Werror=implicit-function-declaration]
perf_fetch_caller_regs(regs);
^
cc1: some warnings being treated as errors
vim +/perf_fetch_caller_regs +1599 net/core/filter.c
1593 static DEFINE_PER_CPU(struct pt_regs, bpf_pt_regs);
1594
1595 static u64 bpf_skb_event_output(u64 r1, u64 r2, u64 flags, u64 r4, u64
size)
1596 {
1597 struct pt_regs *regs = this_cpu_ptr(&bpf_pt_regs);
1598
1599perf_fetch_caller_regs(regs);
1600
1601 return bpf_perf_event_output((long)regs, r2, flags, r4, size);
1602 }
Sorry about that, missed this one. Will fix it up in v2!
Thanks,
Daniel
Re: [PATCH 1/2] [media] atmel-isc: add the Image Sensor Controller code
On 04/13/2016 09:44 AM, Songjun Wu wrote: > Add driver for the Image Sensor Controller. It manages > incoming data from a parallel based CMOS/CCD sensor. > It has an internal image processor, also integrates a > triple channel direct memory access controller master > interface. > > Signed-off-by: Songjun Wu Hi Songjun, Before this driver can be accepted it has to pass the v4l2-compliance test. The v4l2-compliance utility is here: git://linuxtv.org/v4l-utils.git Compile the utility straight from this repository so you're up to date. First fix any failures you get when running 'v4l2-compliance', then do the same when running 'v4l2-compliance -s' (now it is streaming as well) and finally when running 'v4l2-compliance -f' (streaming and testing all available formats). I would like to see the output of 'v4l2-compliance -f' as part of the cover letter of the next patch series. Looking at the code I see that it will definitely fail a few tests :-) Certainly the VIDIOC_CREATE_BUFS support in the queue_setup function is missing. Read the comments for queue_setup in videobuf2-core.h for more information. Regards, Hans
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On Mon, Apr 18, 2016 at 03:21:16PM +0800, Baolin Wang wrote: > > I don't think so, the dm-crypt can not send maximal requests at some > situations. For example, the 'cbc(aes)' cipher, it must be handled > sector by sector (IV is dependency for each sector), so the dm-crypt > can not send maximal requests, but must sector by sector in this > situation. If you can't merge them as requests, then how is the hardware going to benefit from batching them? Or are you talking about parallel processing similar to sha-mb? Even with batching we should be involving the user because only the user knows (if anyone does) whether more data will be forthcoming. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC] shared regulator initialization and protection
Hi, Mark On Tuesday, April 12, 2016 11:48 AM, Mark Brown wrote: > On Tue, Apr 12, 2016 at 10:44:11AM +0800, Pingbo Wen wrote: > > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. Ok, I have re-send another pre-formated email, but you replied to the bad one. Anyway, sorry for this. > >> Those day, I get some fuzz idea in a proxy-consumer regulator driver >> [1] from Qcom kernel tree. The driver is simple, that let some >> critical regulator, which specified in DT tree, initializing in a >> pre-defined state, and hold a regulator consumer during system boot, >> to provide some protection between multi-consumers. > >> And I think this driver is a hint that our upstream code lack of some >> regulator intialization and protection. We already have some regulator > > Given how poorly most of the Qualcom code uses the regulator API I'd > take anything they've got out of tree with a pinch of salt. At best > this looks like a hack for some system specific issues but since it's > just some undocumented code it's hard to tell. > It's hard to tell how many Qualcom code uses the regulator API, I didn't do such investigation. Maybe the 'proxy' consumer driver is just a work-around code, but I don't think it's a reason to prevent us to get some hints from it. >> If a regulator only used by one consumer, current code will work fine. >> But for the regulator which shared between multi-consumers, we can not >> make sure that the regulator will work in a defined-state, during >> system boot, since the device driver can probe in any order, and set >> some conflict attributes. > > What is the actual problem here? Every driver is responsible for > ensuring that regulators are in a good state before it starts using the > hardware, if some other device did something before why do we care? > Yes, I agree the driver should set the regulator before do the real work, when the device life time is started from driver probing. But if the device life time is started before Linux kernel loading, the regulator core should do the regulator initialization and protection to power the device properly, during kernel booting, until the consumer driver probed. > > Anything based on doing things at initcall levels is fundamentally > broken, as soon as things are built modular like most things in a distro > kernel then it'll stop working. If the system integrator needs some > devices to start early to provide continuity (the main case here is > display) they need to deal with that at the system integration level. > Adding a initcall to do the consumer removing is not a decent method. We can do some hack in regulator_get(), removing agent consumer until specified device call regulator_get(), or the first regulator_get(). Pingbo
Re: [PATCH] i2c: tegra: proper handling of error cases
On Sat, Apr 16, 2016 at 08:08:50AM +, Shardar Mohammed wrote: [...] > > > if (!(msg->flags & I2C_M_RD)) > > > tegra_i2c_fill_tx_fifo(i2c_dev); > > > > > > - int_mask = I2C_INT_NO_ACK | I2C_INT_ARBITRATION_LOST; > > > if (i2c_dev->hw->has_per_pkt_xfer_complete_irq) > > > int_mask |= I2C_INT_PACKET_XFER_COMPLETE; > > > if (msg->flags & I2C_M_RD) > > > int_mask |= I2C_INT_RX_FIFO_DATA_REQ; > > > else if (i2c_dev->msg_buf_remaining) > > > int_mask |= I2C_INT_TX_FIFO_DATA_REQ; > > > + > > > tegra_i2c_unmask_irq(i2c_dev, int_mask); > > > > Can this line be removed? The NO_ACK and ARBITRATION_LOST interrupts > > are already unmasked earlier. > > [Shardar] unmask_irq() here is enabling other interrupts > (PACKET_XFER_COMPLETE/TX_FIFO_DATA_REQ/RX_FIFO_DATA_REQ). please let > me know if my understanding is wrong from your comment. You're right, I obviously wasn't looking closely enough. Thierry signature.asc Description: PGP signature
Re: [PATCH 3/6] regulator: rk808: Make rk808 generic, rename rk808-regulator.c
On 15.04.2016 18:24, Alexandre Belloni wrote: > On 15/04/2016 at 11:26:02 +0100, Mark Brown wrote : >> On Fri, Apr 15, 2016 at 11:16:27AM +0200, Wadim Egorov wrote: >> >>> This patch just renames the rk808 driver so we can reuse this driver >>> to add more regulator devices from the RK8XX PMIC family later. >> We normally manage to cope fine without renaming things - it's quite >> common to have drivers that were initially named after one part >> supporting multiple parts, avoiding the rename makes things like >> backports easier and avoids needing git log --follow and so on. > I agree with that and I will also add that probably at some point in > time a new part may appear with a name matching rk8xx but may not be > compatible with the rk8xx driver and that is when the real mess starts. > > Finally, renaming the config options and the modules is not nice for the > user. > OK, renaming the driver and it's config options is not the best idea. But how about renaming the variables and function names within the drivers? It would be more clearer which driver parts are generic and are used by multiple PMIC devices. It seems this topic has been already discussed here [1]. So the right solution is just to rename the rk808 struct in rk808.h, don't touch the driver names and config options and naming the additional RK818 PMIC in the Kconfig? [1] https://lkml.org/lkml/2015/12/31/13
Re: [PATCH] i2c: tegra: proper handling of error cases
On Sat, Apr 16, 2016 at 08:08:50AM +, Shardar Mohammed wrote: > Thanks for the review, updated with comments inline with Shardar. > > > On Fri, Apr 15, 2016 at 06:51:47PM +0530, Shardar Shariff Md wrote: > > > From: Shardar Shariff Md > > > > > > To summarize the issue observed in error cases: > > > > > > In SW: For i2c message transfer, packet header and data payload is > > > posted and then required error/packet completion interrupts are > > > enabled later. > > > > > > In HW flow: HW process the packet just after packet header is posted, > > > if ARB lost/NACK error occurs (SW will not handle immediately when > > > error happens as error interrupts are not enabled at this point). HW > > > assumes error is acknowledged and clears current data in FIFO, But SW > > > here posts the remaining data payload which still stays in FIFO as > > > stale data (data without packet header). > > > > > > Now once the interrupts are enabled, SW handles ARB lost/NACK error by > > > clearing the ARB lost/NACK interrupt. Now HW assumes that SW attended > > > the error and will parse/process stale data (data without packet > > > header) present in FIFO which causes invalid NACK errors. > > > > > > Fix: Enable the error interrupts before posting the packet into FIFO > > > which make sure HW to not clear the fifo. Also disable the packet mode > > > before acknowledging errors (ARB lost/NACK error) to not process any > > > stale data. > > > > > > As error interrupts are enabled before posting the packet header use > > > spinlock to avoid preempting. > > > > Please try to use up the full 78 characters per line in the commit message > > (with the exception being the subject line that should be shorter). > > [Shardar] Will take care of this. I just realized my comment was wrong. The rule is to use 72 characters per line for the commit message. Sorry about that. Thierry signature.asc Description: PGP signature
Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
On 04/18/2016 07:40 AM, tiffany lin wrote:
>
> snipped.
>
>>> +
>>> +void mtk_vcodec_dec_set_default_params(struct mtk_vcodec_ctx *ctx)
>>> +{
>>> + struct mtk_q_data *q_data;
>>> +
>>> + ctx->m2m_ctx->q_lock = &ctx->dev->dev_mutex;
>>> + ctx->fh.m2m_ctx = ctx->m2m_ctx;
>>> + ctx->fh.ctrl_handler = &ctx->ctrl_hdl;
>>> + INIT_WORK(&ctx->decode_work, mtk_vdec_worker);
>>> +
>>> + q_data = &ctx->q_data[MTK_Q_DATA_SRC];
>>> + memset(q_data, 0, sizeof(struct mtk_q_data));
>>> + q_data->visible_width = DFT_CFG_WIDTH;
>>> + q_data->visible_height = DFT_CFG_HEIGHT;
>>> + q_data->fmt = &mtk_video_formats[OUT_FMT_IDX];
>>> + q_data->colorspace = V4L2_COLORSPACE_REC709;
>>> + q_data->field = V4L2_FIELD_NONE;
>>> + ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
>>> + DFT_CFG_WIDTH * DFT_CFG_HEIGHT;
>>> + ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] = 0;
>>> +
>>> +
>>> + q_data = &ctx->q_data[MTK_Q_DATA_DST];
>>> + memset(q_data, 0, sizeof(struct mtk_q_data));
>>> + q_data->visible_width = DFT_CFG_WIDTH;
>>> + q_data->visible_height = DFT_CFG_HEIGHT;
>>> + q_data->coded_width = DFT_CFG_WIDTH;
>>> + q_data->coded_height = DFT_CFG_HEIGHT;
>>> + q_data->colorspace = V4L2_COLORSPACE_REC709;
>>> + q_data->field = V4L2_FIELD_NONE;
>>> +
>>> + q_data->fmt = &mtk_video_formats[CAP_FMT_IDX];
>>> +
>>> + v4l_bound_align_image(&q_data->coded_width,
>>> + MTK_VDEC_MIN_W,
>>> + MTK_VDEC_MAX_W, 4,
>>> + &q_data->coded_height,
>>> + MTK_VDEC_MIN_H,
>>> + MTK_VDEC_MAX_H, 5, 6);
>>> +
>>> + q_data->sizeimage[0] = q_data->coded_width * q_data->coded_height;
>>> + q_data->bytesperline[0] = q_data->coded_width;
>>> + q_data->sizeimage[1] = q_data->sizeimage[0] / 2;
>>> + q_data->bytesperline[1] = q_data->coded_width;
>>> +
>>> +}
>>> +
>>> +static int vidioc_vdec_streamon(struct file *file, void *priv,
>>> + enum v4l2_buf_type type)
>>> +{
>>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +
>>> + mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
>>> +
>>> + return v4l2_m2m_streamon(file, ctx->m2m_ctx, type);
>>> +}
>>> +
>>> +static int vidioc_vdec_streamoff(struct file *file, void *priv,
>>> +enum v4l2_buf_type type)
>>> +{
>>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +
>>> + mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
>>> + return v4l2_m2m_streamoff(file, ctx->m2m_ctx, type);
>>> +}
>>> +
>>> +static int vidioc_vdec_reqbufs(struct file *file, void *priv,
>>> + struct v4l2_requestbuffers *reqbufs)
>>> +{
>>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> + int ret;
>>> +
>>> + mtk_v4l2_debug(3, "[%d] (%d) count=%d", ctx->idx,
>>> +reqbufs->type, reqbufs->count);
>>> + ret = v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
>>> +
>>> + return ret;
>>> +}
>>
>> Please use the v4l2_m2m_ioctl_* helper functions were applicable.
>>
>
>
>
> snipped.
>>> +static unsigned int fops_vcodec_poll(struct file *file,
>>> +struct poll_table_struct *wait)
>>> +{
>>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
>>> + struct mtk_vcodec_dev *dev = ctx->dev;
>>> + int ret;
>>> +
>>> + mutex_lock(&dev->dev_mutex);
>>> + ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait);
>>> + mutex_unlock(&dev->dev_mutex);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int fops_vcodec_mmap(struct file *file, struct vm_area_struct *vma)
>>> +{
>>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
>>> +
>>> + return v4l2_m2m_mmap(file, ctx->m2m_ctx, vma);
>>> +}
>>> +
>>> +static const struct v4l2_file_operations mtk_vcodec_fops = {
>>> + .owner = THIS_MODULE,
>>> + .open = fops_vcodec_open,
>>> + .release= fops_vcodec_release,
>>> + .poll = fops_vcodec_poll,
>>> + .unlocked_ioctl = video_ioctl2,
>>> + .mmap = fops_vcodec_mmap,
>>
>> You should be able to use the v4l2_m2m_fop helper functions for poll and
>> mmap.
>>
>
> Hi Hans,
>
> We are plaining to remove m2m framework in th feature, although we think
Remove it for just the decoder driver or both encoder and decoder?
> it is easy to use and could save a lot of code similar to what m2m
> framework implemented and reduce code size.
> The main reason is that in v4l2_m2m_try_schedule, it required that at
> least one output buffer and one capture buffer to run device_run.
> We want to start device_run without capture buffer queued.
I assume the reason is that you need to get the resolution etc. information
from the encoded stream? Without a capture buffer you can't actually decode
a frame, but that's probably not what this
Re: [PATCH v6 20/24] iio: imu: inv_mpu6050: change the i2c gate to be mux-locked
On Sun, Apr 3, 2016 at 1:54 PM, Jonathan Cameron wrote:
> On 03/04/16 09:52, Peter Rosin wrote:
>> From: Peter Rosin
>>
>> The root i2c adapter lock is then no longer held by the i2c mux during
>> accesses behind the i2c gate, and such accesses need to take that lock
>> just like any other ordinary i2c accesses do.
>>
>> So, declare the i2c gate mux-locked, and zap the code that makes the
>> unlocked i2c accesses and just use ordinary regmap_write accesses.
>>
>> This also happens to fix the deadlock described in
>> http://patchwork.ozlabs.org/patch/584776/ authored by
>> Adriana Reus and submitted by
>> Daniel Baluta
>>
>> --8<--
>> iio: imu: inv_mpu6050: Fix deadlock between i2c adapter lock and mpu lock
>>
>> This deadlock occurs if the accel/gyro and the sensor on the auxiliary
>> I2C (in my setup it's an ak8975) are working at the same time.
>>
>> Scenario:
>>
>> T1 T2
>>
>> inv_mpu6050_read_fifo aux sensor op (eg. ak8975_read_raw)
>> | |
>> mutex_lock(&indio_dev->mlock) i2c_transfer
>> | |
>> i2c transaction i2c adapter lock
>> | |
>> i2c adapter locki2c_mux_master_xfer
>> |
>> inv_mpu6050_select_bypass
>> |
>> mutex_lock(&indio_dev->mlock)
>>
>> When we operate on an mpu sensor the order of locking is mpu lock
>> followed by the i2c adapter lock. However, when we operate the auxiliary
>> sensor the order of locking is the other way around.
>>
>> ...
>> --8<--
>>
>> The reason this patch fixes the deadlock is that T2 does not grab the
>> i2c adapter lock until the very end (and grabs the newfangled i2c mux
>> lock where it previously grabbed the i2c adapter lock).
>>
>> Signed-off-by: Peter Rosin
> This one obviously wants a ack from Adriana or Daniel in addition to mine.
> I'm more than happy for these to go through the i2c tree btw.
>
> Acked-by: Jonathan Cameron
Acked-by: Daniel Baluta
>> ---
>> Documentation/i2c/i2c-topology| 2 +-
>> drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 56
>> +++
>> 2 files changed, 13 insertions(+), 45 deletions(-)
>>
>> diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology
>> index 7a10edd0874f..346623a80bd1 100644
>> --- a/Documentation/i2c/i2c-topology
>> +++ b/Documentation/i2c/i2c-topology
>> @@ -50,7 +50,7 @@ i2c-mux-pinctrl Normally parent-locked,
>> mux-locked iff
>> i2c-mux-reg Parent-locked
>>
>> In drivers/iio/
>> -imu/inv_mpu6050/ Parent-locked
>> +imu/inv_mpu6050/ Mux-locked
>>
>> In drivers/media/
>> dvb-frontends/m88ds3103 Parent-locked
>> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>> b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>> index 0d429d788106..71ad31a275c9 100644
>> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
>> @@ -24,45 +24,16 @@ static const struct regmap_config inv_mpu_regmap_config
>> = {
>> .val_bits = 8,
>> };
>>
>> -/*
>> - * The i2c read/write needs to happen in unlocked mode. As the parent
>> - * adapter is common. If we use locked versions, it will fail as
>> - * the mux adapter will lock the parent i2c adapter, while calling
>> - * select/deselect functions.
>> - */
>> -static int inv_mpu6050_write_reg_unlocked(struct i2c_client *client,
>> - u8 reg, u8 d)
>> -{
>> - int ret;
>> - u8 buf[2] = {reg, d};
>> - struct i2c_msg msg[1] = {
>> - {
>> - .addr = client->addr,
>> - .flags = 0,
>> - .len = sizeof(buf),
>> - .buf = buf,
>> - }
>> - };
>> -
>> - ret = __i2c_transfer(client->adapter, msg, 1);
>> - if (ret != 1)
>> - return ret;
>> -
>> - return 0;
>> -}
>> -
>> static int inv_mpu6050_select_bypass(struct i2c_mux_core *muxc, u32 chan_id)
>> {
>> - struct i2c_client *client = i2c_mux_priv(muxc);
>> - struct iio_dev *indio_dev = dev_get_drvdata(&client->dev);
>> + struct iio_dev *indio_dev = i2c_mux_priv(muxc);
>> struct inv_mpu6050_state *st = iio_priv(indio_dev);
>> int ret = 0;
>>
>> /* Use the same mutex which was used everywhere to protect power-op */
>> mutex_lock(&indio_dev->mlock);
>> if (!st->powerup_count) {
>> - ret = inv_mpu6050_write_reg_unlocked(client,
>> - st->reg->pwr_mgmt_1, 0);
>> + ret = regmap_write(st->map, st->reg->pwr_mgmt_1, 0);
Re: [PATCH v2] i2c: tegra: proper handling of error cases
On Mon, Apr 18, 2016 at 12:04:42PM +0530, Shardar Shariff Md wrote:
> To summarize the issue observed in error cases:
>
> SW Flow: For i2c message transfer, packet header and data payload is posted
> and then required error/packet completion interrupts are enabled later.
>
> HW flow: HW process the packet just after packet header is posted, if ARB
> lost/NACK error occurs (SW will not handle immediately when error happens
> as error interrupts are not enabled at this point). HW assumes error is
> acknowledged and clears current data in FIFO, But SW here posts the
> remaining data payload which still stays in FIFO as stale data (without
> packet header).
>
> Now once the interrupts are enabled, SW handles ARB lost/NACK error by
> clearing the ARB lost/NACK interrupt. Now HW assumes that SW attended the
> error and will parse/process stale data (data without packet header)
> present in FIFO which causes invalid NACK errors.
>
> Fix: Enable the error interrupts before posting the packet into FIFO which
> make sure HW to not clear the fifo. Also disable the packet mode before
> acknowledging errors (ARB lost/NACK error) to not process any stale data.
> As error interrupts are enabled before posting the packet header use
> spinlock to avoid preempting.
>
> Signed-off-by: Shardar Shariff Md
> ---
> drivers/i2c/busses/i2c-tegra.c | 70
> --
> 1 file changed, 54 insertions(+), 16 deletions(-)
It's customary to include a history of your changes in the patch. This
helps reviewers to reload context. You'd typically include it below the
--- separator (below the Signed-off-by). An example might look like
this:
---
Changes since v1:
- blah
- blub
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index d764d64..47345ac 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -191,6 +191,7 @@ struct tegra_i2c_dev {
> u16 clk_divisor_non_hs_mode;
> bool is_suspended;
> bool is_multimaster_mode;
> + spinlock_t xfer_lock;
> };
>
> static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val, unsigned long
> reg)
> @@ -423,12 +424,31 @@ static inline void tegra_i2c_clock_disable(struct
> tegra_i2c_dev *i2c_dev)
> clk_disable(i2c_dev->fast_clk);
> }
>
> +static int tegra_i2c_wait_for_config_load(struct tegra_i2c_dev *i2c_dev)
> +{
> + unsigned long timeout;
> +
> + if (i2c_dev->hw->has_config_load_reg) {
> + i2c_writel(i2c_dev, I2C_MSTR_CONFIG_LOAD, I2C_CONFIG_LOAD);
> + timeout = jiffies + msecs_to_jiffies(1000);
> + while (i2c_readl(i2c_dev, I2C_CONFIG_LOAD) != 0) {
> + if (time_after(jiffies, timeout)) {
> + dev_warn(i2c_dev->dev,
> + "timeout waiting for config load\n");
> + return -ETIMEDOUT;
> + }
> + msleep(1);
> + }
> + }
> +
> + return 0;
> +}
> +
> static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
> {
> u32 val;
> int err = 0;
> u32 clk_divisor;
> - unsigned long timeout = jiffies + HZ;
>
> err = tegra_i2c_clock_enable(i2c_dev);
> if (err < 0) {
> @@ -477,36 +497,42 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
> if (i2c_dev->is_multimaster_mode && i2c_dev->hw->has_slcg_override_reg)
> i2c_writel(i2c_dev, I2C_MST_CORE_CLKEN_OVR, I2C_CLKEN_OVERRIDE);
>
> - if (i2c_dev->hw->has_config_load_reg) {
> - i2c_writel(i2c_dev, I2C_MSTR_CONFIG_LOAD, I2C_CONFIG_LOAD);
> - while (i2c_readl(i2c_dev, I2C_CONFIG_LOAD) != 0) {
> - if (time_after(jiffies, timeout)) {
> - dev_warn(i2c_dev->dev,
> - "timeout waiting for config load\n");
> - return -ETIMEDOUT;
> - }
> - msleep(1);
> - }
> - }
> -
> - tegra_i2c_clock_disable(i2c_dev);
> + err = tegra_i2c_wait_for_config_load(i2c_dev);
> + if (err)
> + goto err;
I think it would still be good to split this into multiple patches to
make it more obvious that you're merely extracting this code to a
function. Perhaps you could mention that you do so because subsequent
patches will reuse the code.
>
> if (i2c_dev->irq_disabled) {
> i2c_dev->irq_disabled = 0;
> enable_irq(i2c_dev->irq);
> }
>
> +err:
> + tegra_i2c_clock_disable(i2c_dev);
> return err;
> }
>
> +static int tegra_i2c_disable_packet_mode(struct tegra_i2c_dev *i2c_dev)
> +{
> + u32 cnfg;
> +
> + cnfg = i2c_readl(i2c_dev, I2C_CNFG);
> + if (cnfg & I2C_CNFG_PACKET_MODE_EN)
> + i2c_writel(i2c_dev, cnfg & ~I2C_CNFG_PACKET_MODE_EN, I2C_CNFG);
> +
> + return tegra_i2c_wait_for_config_loa
[PATCH] regulator: s2mps11: Remove unused set_voltage_time_sel
On S2MPS11 and S2MPS14 devices the default implementation of
set_voltage_time_sel() for LDO regulators was not doing anything useful
because users did not provide ramp delay in Device Tree so the
set_voltage_time_sel() exited with status 0. This could be seen in
dmesg, e.g. on Odroid XU4:
[1.486076] vdd_ldo9: ramp_delay not set
[1.506875] vddq_mmc2: ramp_delay not set
[1.523766] vdd_ldo15: ramp_delay not set
[1.544702] vdd_sd: ramp_delay not set
The datasheet for these devices is inconsistent and does not specify
unambiguously the value of ramp delay for LDO. It mentions 30 mV/us in
one timing diagram but then omits it completely in LDO regulator
characteristics table (it is specified for bucks). To make more
confusion, the vendor kernel for Galaxy S5 and Odroid XU3 uses sometimes
value of 12 mV/us.
Overall, since the ramp delay is not currently provided by DT and it is
unclear what is the correct value anyway, the safest choice seems to be
to remove the implementation of set_voltage_time_sel() for S2MPS11 and
S2MPS14 LDOs thus getting rid of the warning.
Signed-off-by: Krzysztof Kozlowski
---
drivers/regulator/s2mps11.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 64a262f10845..437b1b3b26c9 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -246,7 +246,6 @@ static struct regulator_ops s2mps11_ldo_ops = {
.disable= regulator_disable_regmap,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
- .set_voltage_time_sel = regulator_set_voltage_time_sel,
};
static struct regulator_ops s2mps11_buck_ops = {
@@ -606,7 +605,6 @@ static struct regulator_ops s2mps14_reg_ops = {
.disable= regulator_disable_regmap,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
- .set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_suspend_disable= s2mps14_regulator_set_suspend_disable,
};
--
1.9.1
[PATCH] ARM: dts: exynos: Remove unsupported s2mps11 regulator bindings from Exynos5420 boards
The bindings like s2mps11,buck6-ramp-enable or s2mps11,buck2-ramp-delay
where ignored. They were never parse by s2mps11 regulator driver. Also
the values used in these bindings were equal to default reset values of
S2MPS11 device. It is safe to remove them.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 7 ---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 7 ---
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 7 ---
3 files changed, 21 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index a103ce8c3985..60bc861d0f9d 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -75,13 +75,6 @@
s2mps11_pmic@66 {
compatible = "samsung,s2mps11-pmic";
reg = <0x66>;
- s2mps11,buck2-ramp-delay = <12>;
- s2mps11,buck34-ramp-delay = <12>;
- s2mps11,buck16-ramp-delay = <12>;
- s2mps11,buck6-ramp-enable = <1>;
- s2mps11,buck2-ramp-enable = <1>;
- s2mps11,buck3-ramp-enable = <1>;
- s2mps11,buck4-ramp-enable = <1>;
interrupt-parent = <&gpx3>;
interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 49920b4330ed..2e748d19322f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -140,13 +140,6 @@
s2mps11_pmic@66 {
compatible = "samsung,s2mps11-pmic";
reg = <0x66>;
- s2mps11,buck2-ramp-delay = <12>;
- s2mps11,buck34-ramp-delay = <12>;
- s2mps11,buck16-ramp-delay = <12>;
- s2mps11,buck6-ramp-enable = <1>;
- s2mps11,buck2-ramp-enable = <1>;
- s2mps11,buck3-ramp-enable = <1>;
- s2mps11,buck4-ramp-enable = <1>;
s2mps11_osc: clocks {
#clock-cells = <1>;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 0e71d4253205..20fa7612080d 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -92,13 +92,6 @@
s2mps11_pmic@66 {
compatible = "samsung,s2mps11-pmic";
reg = <0x66>;
- s2mps11,buck2-ramp-delay = <12>;
- s2mps11,buck34-ramp-delay = <12>;
- s2mps11,buck16-ramp-delay = <12>;
- s2mps11,buck6-ramp-enable = <1>;
- s2mps11,buck2-ramp-enable = <1>;
- s2mps11,buck3-ramp-enable = <1>;
- s2mps11,buck4-ramp-enable = <1>;
samsung,s2mps11-acokb-ground;
interrupt-parent = <&gpx0>;
--
1.9.1
Re: [PATCH 02/11] mtd: nand_bbt: introduce BBT related data structure
Hi Peter,
On Mon, 18 Apr 2016 14:22:09 +0800
Peter Pan wrote:
> Hi Boris,
>
> On Fri, Mar 25, 2016 at 4:35 PM, Boris Brezillon
> wrote:
> > Hi Peter,
> >
> > On Mon, 14 Mar 2016 02:47:55 +
> > Peter Pan wrote:
> >
> >> From: Brian Norris
> >>
> >> Currently nand_bbt.c is tied with struct nand_chip, and it makes other
> >> NAND family chips hard to use nand_bbt.c. Maybe it's the reason why
> >> onenand has own bbt(onenand_bbt.c).
> >>
> >> Separate struct nand_chip from BBT code can make current BBT shareable.
> >> We create struct nand_bbt to take place of nand_chip in nand_bbt.c
> >>
> >> Below is mtd folder structure we want:
> >> drivers/mtd/nand/
> >> drivers/mtd/nand/raw/
> >> drivers/mtd/nand/spi/
> >> drivers/mtd/nand/onenand/
> >> drivers/mtd/nand/chips/
> >>
> >> Of course, nand_bbt.c should be part of .
> >>
> >> We put every chip layout related information BBT needed into struct
> >> nand_chip_layout_info.
> >> @numchips: number of physical chips, required for
> >> NAND_BBT_PERCHIP
> >> @chipsize: the size of one chip for multichip arrays
> >> @chip_shift:number of address bits in one chip
> >> @bbt_erase_shift: number of address bits in a bbt entry
> >> @page_shift:number of address bits in a page
> >>
> >> We defined a struct nand_bbt_ops for BBT ops. Struct
> >> @is_bad_bbm:check if a block is factory bad block
> >> @erase: erase block bypassing resvered checks
> >>
> >> Struct nand_bbt includes all BBT information:
> >> @mtd: pointer to MTD device structure
> >> @bbt_options: bad block specific options. All options used
> >> here must come from nand_bbt.h.
> >> @bbt_ops: struct nand_bbt_ops pointer.
> >> @info: struct nand_chip_layout_info pointer.
> >> @bbt_td:bad block table descriptor for flash lookup.
> >> @bbt_md:bad block table mirror descriptor
> >> @bbt: bad block table pointer
> >>
> >> Signed-off-by: Brian Norris
> >> [Peter: 1. correct comment style
> >> 2. introduce struct nand_bbt_ops and nand_chip_layout_info]
> >> Signed-off-by: Peter Pan
> >> ---
> >> include/linux/mtd/nand_bbt.h | 67
> >>
> >> 1 file changed, 67 insertions(+)
> >>
> >> diff --git a/include/linux/mtd/nand_bbt.h b/include/linux/mtd/nand_bbt.h
> >> index 5a65230..cfb22c8 100644
> >> --- a/include/linux/mtd/nand_bbt.h
> >> +++ b/include/linux/mtd/nand_bbt.h
> >> @@ -18,6 +18,8 @@
> >> #ifndef __LINUX_MTD_NAND_BBT_H
> >> #define __LINUX_MTD_NAND_BBT_H
> >>
> >> +struct mtd_info;
> >> +
> >> /* The maximum number of NAND chips in an array */
> >> #define NAND_MAX_CHIPS 8
> >>
> >> @@ -115,4 +117,69 @@ struct nand_bbt_descr {
> >> /* The maximum number of blocks to scan for a bbt */
> >> #define NAND_BBT_SCAN_MAXBLOCKS 4
> >>
> >> +struct nand_bbt;
> >> +
> >> +/**
> >> + * struct nand_bbt_ops - bad block table operations
> >> + * @is_bad_bbm: check if a block is factory bad block
> >> + * @erase: erase block bypassing resvered checks
> >> + */
> >> +struct nand_bbt_ops {
> >> + /*
> >> + * This is important to abstract out of nand_bbt.c and provide
> >> + * separately in nand_base.c and spi-nand-base.c -- it's sort of
> >> + * duplicated in nand_block_bad() (nand_base) and
> >> + * scan_block_fast() (nand_bbt) right now
> >> + *
> >> + * Note that this also means nand_chip.badblock_pattern should
> >> + * be removed from nand_bbt.c
> >> + */
> >> + int (*is_bad_bbm)(struct mtd_info *mtd, loff_t ofs);
> >> +
> >> + /* Erase a block, bypassing reserved checks */
> >> + int (*erase)(struct mtd_info *mtd, loff_t ofs);
> >> +};
> >> +
> >> +/**
> >> + * struct nand_chip_layout_info - strucure contains all chip layout
> >> + * information that BBT needed.
> >> + * @numchips:number of physical chips, required for
> >> NAND_BBT_PERCHIP
> >> + * @chipsize:the size of one chip for multichip arrays
> >> + * @chip_shift: number of address bits in one chip
> >> + * @bbt_erase_shift: number of address bits in a bbt entry
> >> + * @page_shift: number of address bits in a page
> >> + */
> >> +struct nand_chip_layout_info {
> >
> > I know I'm the one who suggested this name, but NAND datasheet seems to
> > call it "memory organization", so maybe we should rename this struct
> > nand_memory_organization.
> >
> >> + int numchips;
> >
> > I would rename it numdies, or ndies. numchips implies you're having
> > several chips, which is not the case.
>
> In struct nand_chip and nand_base.c, numchips stands for the number of
> physical nand chips not number of dies(LUNs), am I right?
I don't know what was the initial meaning for ->numchips, but last time
we discussed that with Brian, he seemed to agree that this should now
encode the number of die
[GIT PULL] s390 patches for 4.6-rc5
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates:
A couple of bug fixes.
Gerald Schaefer (1):
s390/dcssblk: fix possible deadlock in remove vs. per-device attributes
Heiko Carstens (2):
s390/spinlock: avoid yield to non existent cpu
s390: add CPU_BIG_ENDIAN config option
Sebastian Ott (2):
s390/scm_blk: fix deadlock for requests != REQ_TYPE_FS
s390/pci: add extra padding to function measurement block
Sudip Mukherjee (1):
s390/seccomp: include generic seccomp header file
arch/s390/Kconfig | 3 +++
arch/s390/include/asm/pci.h | 3 ++-
arch/s390/include/asm/seccomp.h | 2 ++
arch/s390/lib/spinlock.c| 1 +
drivers/s390/block/dcssblk.c| 5 +++--
drivers/s390/block/scm_blk.c| 2 +-
6 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index aad23e3..bf24ab1 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -4,6 +4,9 @@ config MMU
config ZONE_DMA
def_bool y
+config CPU_BIG_ENDIAN
+ def_bool y
+
config LOCKDEP_SUPPORT
def_bool y
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index b6bfa16..535a46d 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -44,7 +44,8 @@ struct zpci_fmb {
u64 rpcit_ops;
u64 dma_rbytes;
u64 dma_wbytes;
-} __packed __aligned(64);
+ u64 pad[2];
+} __packed __aligned(128);
enum zpci_state {
ZPCI_FN_STATE_RESERVED,
diff --git a/arch/s390/include/asm/seccomp.h b/arch/s390/include/asm/seccomp.h
index 781a9cf..e10f833 100644
--- a/arch/s390/include/asm/seccomp.h
+++ b/arch/s390/include/asm/seccomp.h
@@ -13,4 +13,6 @@
#define __NR_seccomp_exit_32 __NR_exit
#define __NR_seccomp_sigreturn_32 __NR_sigreturn
+#include
+
#endif /* _ASM_S390_SECCOMP_H */
diff --git a/arch/s390/lib/spinlock.c b/arch/s390/lib/spinlock.c
index d4549c9..e5f50a7 100644
--- a/arch/s390/lib/spinlock.c
+++ b/arch/s390/lib/spinlock.c
@@ -105,6 +105,7 @@ void arch_spin_lock_wait_flags(arch_spinlock_t *lp,
unsigned long flags)
if (_raw_compare_and_swap(&lp->lock, 0, cpu))
return;
local_irq_restore(flags);
+ continue;
}
/* Check if the lock owner is running. */
if (first_diag && cpu_is_preempted(~owner)) {
diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
index 1bce9cf..b839086 100644
--- a/drivers/s390/block/dcssblk.c
+++ b/drivers/s390/block/dcssblk.c
@@ -756,15 +756,16 @@ dcssblk_remove_store(struct device *dev, struct
device_attribute *attr, const ch
blk_cleanup_queue(dev_info->dcssblk_queue);
dev_info->gd->queue = NULL;
put_disk(dev_info->gd);
- device_unregister(&dev_info->dev);
/* unload all related segments */
list_for_each_entry(entry, &dev_info->seg_list, lh)
segment_unload(entry->segment_name);
- put_device(&dev_info->dev);
up_write(&dcssblk_devices_sem);
+ device_unregister(&dev_info->dev);
+ put_device(&dev_info->dev);
+
rc = count;
out_buf:
kfree(local_buf);
diff --git a/drivers/s390/block/scm_blk.c b/drivers/s390/block/scm_blk.c
index 75d9896..e6f54d3 100644
--- a/drivers/s390/block/scm_blk.c
+++ b/drivers/s390/block/scm_blk.c
@@ -303,7 +303,7 @@ static void scm_blk_request(struct request_queue *rq)
if (req->cmd_type != REQ_TYPE_FS) {
blk_start_request(req);
blk_dump_rq_flags(req, KMSG_COMPONENT " bad request");
- blk_end_request_all(req, -EIO);
+ __blk_end_request_all(req, -EIO);
continue;
}
Re: [PATCH v6 02/12] usb: hcd.h: Add OTG to HCD interface
On Tue, Apr 05, 2016 at 05:05:07PM +0300, Roger Quadros wrote:
> The OTG core will use struct otg_hcd_ops to interface
> with the HCD controller.
>
> The main purpose of this interface is to avoid directly
> calling HCD APIs from the OTG core as they
> wouldn't be defined in the built-in symbol table if
> CONFIG_USB is m.
>
> Signed-off-by: Roger Quadros
> ---
> include/linux/usb/hcd.h | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
> index b98f831..861ccaa 100644
> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -399,6 +399,30 @@ struct hc_driver {
>
> };
>
> +/**
> + * struct otg_hcd_ops - Interface between OTG core and HCD
> + *
> + * Provided by the HCD core to allow the OTG core to interface with the HCD
> + *
> + * @add: function to add the HCD
> + * @remove: function to remove the HCD
> + * @usb_bus_start_enum: function to immediately start bus enumeration
> + * @usb_control_msg: function to build and send of a control urb
> + * @usb_hub_find_child: function to get pointer to the child device
> + */
> +struct otg_hcd_ops {
> + int (*add)(struct usb_hcd *hcd,
> +unsigned int irqnum, unsigned long irqflags);
> + void (*remove)(struct usb_hcd *hcd);
> + int (*usb_bus_start_enum)(struct usb_bus *bus, unsigned int port_num);
> + int (*usb_control_msg)(struct usb_device *dev, unsigned int pipe,
> +__u8 request, __u8 requesttype, __u16 value,
> +__u16 index, void *data, __u16 size,
> +int timeout);
> + struct usb_device * (*usb_hub_find_child)(struct usb_device *hdev,
> + int port1);
> +};
> +
> static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)
> {
> return hcd->driver->flags & HCD_BH;
> --
> 2.5.0
>
Acked-by: Peter Chen
--
Best Regards,
Peter Chen
Re: [PATCH v3 1/1] mfd: intel-lpss: save register context on suspend
On Fri, 15 Apr 2016, Andy Shevchenko wrote: > On Wed, 2016-03-30 at 16:54 +0300, Heikki Krogerus wrote: > > Hi, > > > > On Wed, Mar 30, 2016 at 04:35:46PM +0300, Andy Shevchenko wrote: > > > > > > From: Heikki Krogerus > > > > > > All configurations are lost and the registers will have > > > default values when the hardware is suspended and resumed, > > > so saving the private register space context on suspend, and > > > restoring it on resume. > > > > > > Signed-off-by: Heikki Krogerus > > > Acked-by: Lee Jones > > Lee's Ack? I'm confused? Who is meant to take this patch? > > > > > > > > --- > > > Since v2: > > > - add Ack > > > - remove Fixes tag > > Why? This is a fix. And it also needs to go into the stable trees as > > well, so we will also need tag it with "Cc: sta...@vger.kernel.org". > > So, in that case v2 is what you want, right? > > Lee, do I need to resend v2 as v4 or something else is required? If you need a further change, please submit it as v4. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v6 03/12] usb: otg-fsm: use usb_otg wherever possible
On Tue, Apr 05, 2016 at 05:05:08PM +0300, Roger Quadros wrote:
> Move otg_fsm into usb_otg and use usb_otg wherever possible
> in the usb_otg APIs.
>
> Signed-off-by: Roger Quadros
Acked-by: Peter Chen
> ---
> drivers/usb/chipidea/ci.h| 1 -
> drivers/usb/chipidea/core.c | 12 +--
> drivers/usb/chipidea/debug.c | 2 +-
> drivers/usb/chipidea/otg_fsm.c | 171 ++---
> drivers/usb/chipidea/udc.c | 17 ++--
> drivers/usb/common/usb-otg-fsm.c | 180
> ---
> drivers/usb/phy/phy-fsl-usb.c| 143 +++
> drivers/usb/phy/phy-fsl-usb.h| 3 +-
> include/linux/usb/otg-fsm.h | 132 +++-
> include/linux/usb/otg.h | 107 +++
> 10 files changed, 384 insertions(+), 384 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index cd41455..c523975 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -209,7 +209,6 @@ struct ci_hdrc {
> enum ci_rolerole;
> boolis_otg;
> struct usb_otg otg;
> - struct otg_fsm fsm;
> struct hrtimer otg_fsm_hrtimer;
> ktime_t hr_timeouts[NUM_OTG_FSM_TIMERS];
> unsignedenabled_otg_timer_bits;
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 69426e6..a5570a9 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -1085,7 +1085,7 @@ static int ci_hdrc_remove(struct platform_device *pdev)
> /* Prepare wakeup by SRP before suspend */
> static void ci_otg_fsm_suspend_for_srp(struct ci_hdrc *ci)
> {
> - if ((ci->fsm.otg->state == OTG_STATE_A_IDLE) &&
> + if ((ci->otg.state == OTG_STATE_A_IDLE) &&
> !hw_read_otgsc(ci, OTGSC_ID)) {
> hw_write(ci, OP_PORTSC, PORTSC_W1C_BITS | PORTSC_PP,
> PORTSC_PP);
> @@ -1097,13 +1097,13 @@ static void ci_otg_fsm_suspend_for_srp(struct ci_hdrc
> *ci)
> /* Handle SRP when wakeup by data pulse */
> static void ci_otg_fsm_wakeup_by_srp(struct ci_hdrc *ci)
> {
> - if ((ci->fsm.otg->state == OTG_STATE_A_IDLE) &&
> - (ci->fsm.a_bus_drop == 1) && (ci->fsm.a_bus_req == 0)) {
> + if ((ci->otg.state == OTG_STATE_A_IDLE) &&
> + (ci->otg.fsm.a_bus_drop == 1) && (ci->otg.fsm.a_bus_req == 0)) {
> if (!hw_read_otgsc(ci, OTGSC_ID)) {
> - ci->fsm.a_srp_det = 1;
> - ci->fsm.a_bus_drop = 0;
> + ci->otg.fsm.a_srp_det = 1;
> + ci->otg.fsm.a_bus_drop = 0;
> } else {
> - ci->fsm.id = 1;
> + ci->otg.fsm.id = 1;
> }
> ci_otg_queue_work(ci);
> }
> diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
> index 6d23eed..374cdaa 100644
> --- a/drivers/usb/chipidea/debug.c
> +++ b/drivers/usb/chipidea/debug.c
> @@ -224,7 +224,7 @@ static int ci_otg_show(struct seq_file *s, void *unused)
> if (!ci || !ci_otg_is_fsm_mode(ci))
> return 0;
>
> - fsm = &ci->fsm;
> + fsm = &ci->otg.fsm;
>
> /* -- State - */
> seq_printf(s, "OTG state: %s\n\n",
> diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
> index 5f169b3..f4e9fb5 100644
> --- a/drivers/usb/chipidea/otg_fsm.c
> +++ b/drivers/usb/chipidea/otg_fsm.c
> @@ -40,7 +40,7 @@ get_a_bus_req(struct device *dev, struct device_attribute
> *attr, char *buf)
>
> next = buf;
> size = PAGE_SIZE;
> - t = scnprintf(next, size, "%d\n", ci->fsm.a_bus_req);
> + t = scnprintf(next, size, "%d\n", ci->otg.fsm.a_bus_req);
> size -= t;
> next += t;
>
> @@ -56,25 +56,25 @@ set_a_bus_req(struct device *dev, struct device_attribute
> *attr,
> if (count > 2)
> return -1;
>
> - mutex_lock(&ci->fsm.lock);
> + mutex_lock(&ci->otg.fsm.lock);
> if (buf[0] == '0') {
> - ci->fsm.a_bus_req = 0;
> + ci->otg.fsm.a_bus_req = 0;
> } else if (buf[0] == '1') {
> /* If a_bus_drop is TRUE, a_bus_req can't be set */
> - if (ci->fsm.a_bus_drop) {
> - mutex_unlock(&ci->fsm.lock);
> + if (ci->otg.fsm.a_bus_drop) {
> + mutex_unlock(&ci->otg.fsm.lock);
> return count;
> }
> - ci->fsm.a_bus_req = 1;
> - if (ci->fsm.otg->state == OTG_STATE_A_PERIPHERAL) {
> + ci->otg.fsm.a_bus_req = 1;
> + if (ci->otg.state == OTG_STATE_A_PERIPHERAL) {
> ci->gadget.host_request_flag = 1;
> - mutex_unlo
Re: [PATCH] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared
Hello,
On 2016-04-16 00:04, Javier Martinez Canillas wrote:
The exynos5 I2C controller driver always prepares and enables a clock
before using it and then disables unprepares it when the clock is not
used anymore.
But this can cause a possible ABBA deadlock in some scenarios since a
driver that uses regmap to access its I2C registers, will first grab
the regmap lock and then the I2C xfer function will grab the prepare
lock when preparing the I2C clock. But since the clock driver also
uses regmap for I2C accesses, preparing a clock will first grab the
prepare lock and then the regmap lock when using the regmap API.
An example of this happens on the Exynos5422 Odroid XU board where a
s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
share the same I2C regmap.
The possible deadlock is reported by the kernel lockdep:
Possible unsafe locking scenario:
CPU0CPU1
lock(sec_core:428:(regmap)->lock);
lock(prepare_lock);
lock(sec_core:428:(regmap)->lock);
lock(prepare_lock);
*** DEADLOCK ***
Fix this by only preparing the clock on probe and {en,dis}able in the
rest of the driver.
This patch is similar to commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA
deadlock by keeping clock prepared") that fixes the same bug in other
driver for an I2C controller found in Samsung SoCs.
I'm sorry, but this is not the right approach imho. It is just a workaround
applied to specific driver, it also duplicates incorrect clock usage
pattern (there is really no point keeping clock prepared all the time).
IMHO this ABBA deadlock should be really fixed in clocks core (probably
by removing global prepare mutex and replacing it with per clock
controller mutexes). Without a proper patch this issue will hit us again
with other i2c controllers or other drivers as well.
Reported-by: Anand Moon
Signed-off-by: Javier Martinez Canillas
---
drivers/i2c/busses/i2c-exynos5.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index b29c7500461a..602633747149 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -671,7 +671,9 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
return -EIO;
}
- clk_prepare_enable(i2c->clk);
+ ret = clk_enable(i2c->clk);
+ if (ret)
+ return ret;
for (i = 0; i < num; i++, msgs++) {
stop = (i == num - 1);
@@ -695,7 +697,7 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
}
out:
- clk_disable_unprepare(i2c->clk);
+ clk_disable(i2c->clk);
return ret;
}
@@ -799,6 +801,10 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, i2c);
+ clk_disable(i2c->clk);
+
+ return 0;
+
err_clk:
clk_disable_unprepare(i2c->clk);
return ret;
@@ -810,6 +816,8 @@ static int exynos5_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(&i2c->adap);
+ clk_unprepare(i2c->clk);
+
return 0;
}
@@ -830,16 +838,18 @@ static int exynos5_i2c_resume_noirq(struct device *dev)
struct exynos5_i2c *i2c = platform_get_drvdata(pdev);
int ret = 0;
- clk_prepare_enable(i2c->clk);
+ ret = clk_enable(i2c->clk);
+ if (ret)
+ return ret;
ret = exynos5_hsi2c_clock_setup(i2c);
if (ret) {
- clk_disable_unprepare(i2c->clk);
+ clk_disable(i2c->clk);
return ret;
}
exynos5_i2c_init(i2c);
- clk_disable_unprepare(i2c->clk);
+ clk_disable(i2c->clk);
i2c->suspended = 0;
return 0;
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH 1/1] i2c: dln2: Pass forward ACPI companion
On Sat, Apr 16, 2016 at 11:33:04PM +0200, Wolfram Sang wrote: > On Thu, Mar 24, 2016 at 08:59:16PM +0200, Irina Tirdea wrote: > > Share the ACPI companion for the platform device with the > > i2c adapter, so that the adapter has access to the properties > > defined in ACPI tables. > > > > Signed-off-by: Irina Tirdea > > --- > > Adding Mika for my question: A few drivers do this, does it make sense > to put this into the core? It is pretty much dependent on the driver in question, how it wants to deal with the ACPI companion. DT does the same for of_node: ACPI_COMPANION_SET(&dln2->adapter.dev, ACPI_COMPANION(&pdev->dev)); dln2->adapter.dev.of_node = dev->of_node; > Apart from that, looks good to me. Looks good to me too. > > drivers/i2c/busses/i2c-dln2.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/i2c/busses/i2c-dln2.c b/drivers/i2c/busses/i2c-dln2.c > > index 1600edd..f2eb4f7 100644 > > --- a/drivers/i2c/busses/i2c-dln2.c > > +++ b/drivers/i2c/busses/i2c-dln2.c > > @@ -19,6 +19,7 @@ > > #include > > #include > > #include > > +#include > > > > #define DLN2_I2C_MODULE_ID 0x03 > > #define DLN2_I2C_CMD(cmd) DLN2_CMD(cmd, DLN2_I2C_MODULE_ID) > > @@ -210,6 +211,7 @@ static int dln2_i2c_probe(struct platform_device *pdev) > > dln2->adapter.algo = &dln2_i2c_usb_algorithm; > > dln2->adapter.quirks = &dln2_i2c_quirks; > > dln2->adapter.dev.parent = dev; > > + ACPI_COMPANION_SET(&dln2->adapter.dev, ACPI_COMPANION(&pdev->dev)); > > dln2->adapter.dev.of_node = dev->of_node; > > i2c_set_adapdata(&dln2->adapter, dln2); > > snprintf(dln2->adapter.name, sizeof(dln2->adapter.name), "%s-%s-%d", > > -- > > 1.9.1 > >
Re: zram: per-cpu compression streams
Hello Minchan, sorry, it took me so long to return back to testing. I collected extended stats (perf), just like you requested. - 3G zram, lzo; 4 CPU x86_64 box. - fio with perf stat 4 streams8 streams per-cpu === #jobs1 READ: 2520.1MB/s 2566.5MB/s 2491.5MB/s READ: 2102.7MB/s 2104.2MB/s 2091.3MB/s WRITE: 1355.1MB/s 1320.2MB/s 1378.9MB/s WRITE: 1103.5MB/s 1097.2MB/s 1122.5MB/s READ: 434013KB/s 435153KB/s 439961KB/s WRITE: 433969KB/s 435109KB/s 439917KB/s READ: 403166KB/s 405139KB/s 403373KB/s WRITE: 403223KB/s 405197KB/s 403430KB/s #jobs2 READ: 7958.6MB/s 8105.6MB/s 8073.7MB/s READ: 6864.9MB/s 6989.8MB/s 7021.8MB/s WRITE: 2438.1MB/s 2346.9MB/s 3400.2MB/s WRITE: 1994.2MB/s 1990.3MB/s 2941.2MB/s READ: 981504KB/s 973906KB/s 1018.8MB/s WRITE: 981659KB/s 974060KB/s 1018.1MB/s READ: 937021KB/s 938976KB/s 987250KB/s WRITE: 934878KB/s 936830KB/s 984993KB/s #jobs3 READ: 13280MB/s13553MB/s 13553MB/s READ: 11534MB/s11785MB/s 11755MB/s WRITE: 3456.9MB/s 3469.9MB/s 4810.3MB/s WRITE: 3029.6MB/s 3031.6MB/s 4264.8MB/s READ: 1363.8MB/s 1362.6MB/s 1448.9MB/s WRITE: 1361.9MB/s 1360.7MB/s 1446.9MB/s READ: 1309.4MB/s 1310.6MB/s 1397.5MB/s WRITE: 1307.4MB/s 1308.5MB/s 1395.3MB/s #jobs4 READ: 20244MB/s20177MB/s 20344MB/s READ: 17886MB/s17913MB/s 17835MB/s WRITE: 4071.6MB/s 4046.1MB/s 6370.2MB/s WRITE: 3608.9MB/s 3576.3MB/s 5785.4MB/s READ: 1824.3MB/s 1821.6MB/s 1997.5MB/s WRITE: 1819.8MB/s 1817.4MB/s 1992.5MB/s READ: 1765.7MB/s 1768.3MB/s 1937.3MB/s WRITE: 1767.5MB/s 1769.1MB/s 1939.2MB/s #jobs5 READ: 18663MB/s18986MB/s 18823MB/s READ: 16659MB/s16605MB/s 16954MB/s WRITE: 3912.4MB/s 3888.7MB/s 6126.9MB/s WRITE: 3506.4MB/s 3442.5MB/s 5519.3MB/s READ: 1798.2MB/s 1746.5MB/s 1935.8MB/s WRITE: 1792.7MB/s 1740.7MB/s 1929.1MB/s READ: 1727.6MB/s 1658.2MB/s 1917.3MB/s WRITE: 1726.5MB/s 1657.2MB/s 1916.6MB/s #jobs6 READ: 21017MB/s20922MB/s 21162MB/s READ: 19022MB/s19140MB/s 18770MB/s WRITE: 3968.2MB/s 4037.7MB/s 6620.8MB/s WRITE: 3643.5MB/s 3590.2MB/s 6027.5MB/s READ: 1871.8MB/s 1880.5MB/s 2049.9MB/s WRITE: 1867.8MB/s 1877.2MB/s 2046.2MB/s READ: 1755.8MB/s 1710.3MB/s 1964.7MB/s WRITE: 1750.5MB/s 1705.9MB/s 1958.8MB/s #jobs7 READ: 21103MB/s20677MB/s 21482MB/s READ: 18522MB/s18379MB/s 19443MB/s WRITE: 4022.5MB/s 4067.4MB/s 6755.9MB/s WRITE: 3691.7MB/s 3695.5MB/s 5925.6MB/s READ: 1841.5MB/s 1933.9MB/s 2090.5MB/s WRITE: 1842.7MB/s 1935.3MB/s 2091.9MB/s READ: 1832.4MB/s 1856.4MB/s 1971.5MB/s WRITE: 1822.3MB/s 1846.2MB/s 1960.6MB/s #jobs8 READ: 20463MB/s20194MB/s 20862MB/s READ: 18178MB/s17978MB/s 18299MB/s WRITE: 4085.9MB/s 4060.2MB/s 7023.8MB/s WRITE: 3776.3MB/s 3737.9MB/s 6278.2MB/s READ: 1957.6MB/s 1944.4MB/s 2109.5MB/s WRITE: 1959.2MB/s 1946.2MB/s 2111.4MB/s READ: 1900.6MB/s 1885.7MB/s 2082.1MB/s WRITE: 1896.2MB/s 1881.4MB/s 2078.3MB/s #jobs9 READ: 19692MB/s19734MB/s 19334MB/s READ: 17678MB/s18249MB/s 17666MB/s WRITE: 4004.7MB/s 4064.8MB/s 6990.7MB/s WRITE: 3724.7MB/s 3
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On 18 April 2016 at 15:24, Herbert Xu wrote: > On Mon, Apr 18, 2016 at 03:21:16PM +0800, Baolin Wang wrote: >> >> I don't think so, the dm-crypt can not send maximal requests at some >> situations. For example, the 'cbc(aes)' cipher, it must be handled >> sector by sector (IV is dependency for each sector), so the dm-crypt >> can not send maximal requests, but must sector by sector in this >> situation. > > If you can't merge them as requests, then how is the hardware going > to benefit from batching them? Or are you talking about parallel That depends on the hardware engine. Some cipher hardware engines (like xts(aes) engine) can handle the intermediate values (IV) by themselves in one bulk block, which means we can increase the size of the request by merging request rather than always 512 bytes and thus increase the hardware engine processing speed. But for some other hardware engines (like cbc(aes) engine), they can not support bulk block, must sector by sector. So the engine drivers can select the suitable mode to do encryption/decryption. > processing similar to sha-mb? > > Even with batching we should be involving the user because only the > user knows (if anyone does) whether more data will be forthcoming. If this cipher engine can support bulk block encryption, the crypto engine framework can merge requests if they are eligible automatically. Don't need to worry about how many data will be forthcoming. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Baolin.wang Best Regards
[PATCH v2 1/1] powerpc/86xx: Add support for Emerson/Artesyn MVME7100
Add support for the Artesyn MVME7100 Single Board Computer.
The MVME7100 is a 6U form factor VME64 computer with:
- A two e600 cores Freescale MPC8641D CPU
- 2 GB of DDR2 onboard memory
- Four Gigabit Ethernets
- Five 16550 compatible UARTs
- One USB 2.0 port
- Two PCI/PCI eXpress Mezzanine Card (PMC/XMC) Slots
- A DS1375 Real Time Clock (RTC)
- 512 KB of Non-Volatile Memory (NVRAM)
- Two 64 KB EEPROMs
- 128 MB NOR and 4/8 GB NAND Flash
This patch is based on linux-4.6-rc4 and has been only boot tested.
Signed-off-by: Alessio Igor Bogani
---
v1 -> v2
Fix BCSR handling
Add missing @interrupt-cells in the device tree
to avoid 'of_irq_parse_pci() failed with rc=-22'
Reduce from 3 to 2 the PCI windows to avoid
'Ran out of outbound PCI ATMUs for IO resource'
This patch requires
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-April/141813.html
to be built and
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-April/141785.html to
work correctly.
Limitations:
This patch covers only models 171 and 173
No plans to support CPLD timers
Know issues:
All four PHYs work in polling mode
Configuration is missing for:
PCI IDSEL and PCI Interrupt definition
Support is missing for:
Cache and memory controllers (which are very similar to the 85xx ones
but right now I don't know if we can re-use their support)
Watchdog, USB, NVRAM, NOR, NAND, EEPROMs, VME, PMC/XMC and RTC
arch/powerpc/boot/Makefile | 4 +
arch/powerpc/boot/dts/fsl/mvme7100.dts | 206 +++
arch/powerpc/boot/mvme7100.c | 70 +
arch/powerpc/boot/ppcboot.h | 2 +-
arch/powerpc/boot/wrapper| 4 +
arch/powerpc/configs/mpc86xx_basic_defconfig | 1 +
arch/powerpc/platforms/86xx/Kconfig | 7 +-
arch/powerpc/platforms/86xx/Makefile | 1 +
arch/powerpc/platforms/86xx/mvme7100.c | 124
9 files changed, 417 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/mvme7100.dts
create mode 100644 arch/powerpc/boot/mvme7100.c
create mode 100644 arch/powerpc/platforms/86xx/mvme7100.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8fe78a3..2c75fdb 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -113,6 +113,7 @@ src-plat-$(CONFIG_EPAPR_BOOT) += epapr.c epapr-wrapper.c
src-plat-$(CONFIG_PPC_PSERIES) += pseries-head.S
src-plat-$(CONFIG_PPC_POWERNV) += pseries-head.S
src-plat-$(CONFIG_PPC_IBM_CELL_BLADE) += pseries-head.S
+src-plat-$(CONFIG_MVME7100) += mvme7100.c
src-wlib := $(sort $(src-wlib-y))
src-plat := $(sort $(src-plat-y))
@@ -296,6 +297,9 @@ image-$(CONFIG_TQM8560) +=
cuImage.tqm8560
image-$(CONFIG_SBC8548)+= cuImage.sbc8548
image-$(CONFIG_KSI8560)+= cuImage.ksi8560
+# Board ports in arch/powerpc/platform/86xx/Kconfig
+image-$(CONFIG_MVME7100)+= dtbImage.mvme7100
+
# Board ports in arch/powerpc/platform/embedded6xx/Kconfig
image-$(CONFIG_STORCENTER) += cuImage.storcenter
image-$(CONFIG_MPC7448HPC2)+= cuImage.mpc7448hpc2
diff --git a/arch/powerpc/boot/dts/fsl/mvme7100.dts
b/arch/powerpc/boot/dts/fsl/mvme7100.dts
new file mode 100644
index 000..2fdb912
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/mvme7100.dts
@@ -0,0 +1,206 @@
+/*
+ * Device tree source for the Emerson/Artesyn MVME7100
+ *
+ * Copyright 2016 Elettra-Sincrotrone Trieste S.C.p.A.
+ *
+ * Author: Alessio Igor Bogani
+ *
+ * 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/ "mpc8641si-pre.dtsi"
+
+/ {
+ model = "MVME7100";
+ compatible = "artesyn,MVME7100";
+
+ aliases {
+ pci1 = &pci1;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x8000>;
+ };
+
+ soc: soc@f100 {
+ ranges = <0x 0xf100 0x0010>;
+
+ i2c@3000 {
+ hwmon@4c {
+ compatible = "dallas,max6649";
+ reg = <0x4c>;
+ };
+
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ };
+ };
+
+
+ enet0: ethernet@24000 {
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ mdio@24520 {
+ phy0: ethernet-phy@1 {
+ reg = <1>;
+
RE: [PATCH v2 0/2] usb: dwc3: add disable receiver detection in P3 quirk
Hi, Rajesh Bhagat writes: >>-Original Message- >>From: Rajesh Bhagat [mailto:rajesh.bha...@nxp.com] >>Sent: Monday, March 14, 2016 2:41 PM >>To: ba...@ti.com >>Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux- >>ker...@vger.kernel.org; linux-o...@vger.kernel.org; Sriram Dash >>; Rajesh Bhagat >>Subject: [PATCH v2 0/2] usb: dwc3: add disable receiver detection in P3 >>quirk >> >>Adds disable receiver detection in P3 quirk in DWC3 driver. >> >>Rajesh Bhagat (2): >> usb: dwc3: add disable receiver detection in P3 quirk >> Documentation: dt: dwc3: Add snps,dis_rxdet_inp3_quirk property >> >> Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++ >> drivers/usb/dwc3/core.c| 6 ++ >> drivers/usb/dwc3/core.h| 2 ++ >> drivers/usb/dwc3/platform_data.h | 1 + >> 4 files changed, 11 insertions(+) >> > > Hello Felipe, > > Any comments on above [v2] patches? > https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=ddf332eb6a5379c3f4bcade6760ae41bcd8f2202 https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=bdeb03b4ed887a36595fc8ccdd04f82e718e9ab4 -- balbi signature.asc Description: PGP signature
[PATCH v2] arm64: Reduce verbosity on SMP CPU stop
On Fri, Apr 15, 2016 at 12:37:06PM +0100, Will Deacon wrote:
> You can remove stop_lock altogether now, right? I also wonder whether
> it would be worth printing out which CPUs are still online in the case where
> we fail to stop all the secondaries?
Sorry, I've been a bit offline. Yes, the stop_lock can also be removed.
How about below patch that prints the CPU ids for all CPUs that failed
to stop?
Jan
When CPUs are stopped during an abnormal operation like panic
for each CPU a line is printed and the stack trace is dumped.
This information is only interesting for the aborting CPU
and on systems with many CPUs it only makes it harder to
debug if after the aborting CPU the log is flooded with data
about all other CPUs too.
Therefore remove the stack dump and printk of other CPUs
and only print a single line that the other CPUs are going to be
stopped and, in case any CPUs remain online list them.
Signed-off-by: Jan Glauber
---
arch/arm64/kernel/smp.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index b2d5f4e..29f4e37 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -763,21 +763,11 @@ void arch_irq_work_raise(void)
}
#endif
-static DEFINE_RAW_SPINLOCK(stop_lock);
-
/*
* ipi_cpu_stop - handle IPI from smp_send_stop()
*/
static void ipi_cpu_stop(unsigned int cpu)
{
- if (system_state == SYSTEM_BOOTING ||
- system_state == SYSTEM_RUNNING) {
- raw_spin_lock(&stop_lock);
- pr_crit("CPU%u: stopping\n", cpu);
- dump_stack();
- raw_spin_unlock(&stop_lock);
- }
-
set_cpu_online(cpu, false);
local_irq_disable();
@@ -872,6 +862,9 @@ void smp_send_stop(void)
cpumask_copy(&mask, cpu_online_mask);
cpumask_clear_cpu(smp_processor_id(), &mask);
+ if (system_state == SYSTEM_BOOTING ||
+ system_state == SYSTEM_RUNNING)
+ pr_crit("SMP: stopping secondary CPUs\n");
smp_cross_call(&mask, IPI_CPU_STOP);
}
@@ -881,7 +874,8 @@ void smp_send_stop(void)
udelay(1);
if (num_online_cpus() > 1)
- pr_warning("SMP: failed to stop secondary CPUs\n");
+ pr_warning("SMP: failed to stop secondary CPUs %*pbl\n",
+ cpumask_pr_args(cpu_online_mask));
}
/*
--
1.9.1
Re: [PATCH] macsec: fix crypto Kconfig dependency
Arnd Bergmann wrote:
> The new MACsec driver uses the AES crypto algorithm, but can be configured
> even if CONFIG_CRYPTO is disabled, leading to a build error:
>
> warning: (MAC80211 && MACSEC) selects CRYPTO_GCM which has unmet direct
> dependencies (CRYPTO)
> warning: (BT && CEPH_LIB && INET && MAC802154 && MAC80211 && BLK_DEV_RBD &&
> MACSEC && AIRO_CS && LIBIPW && HOSTAP && USB_WUSB && RTLLIB_CRYPTO_CCMP &&
> FS_ENCRYPTION && EXT4_ENCRYPTION && CEPH_FS && BIG_KEYS && ENCRYPTED_KEYS)
> selects CRYPTO_AES which has unmet direct dependencies (CRYPTO)
> crypto/built-in.o: In function `gcm_enc_copy_hash':
> aes_generic.c:(.text+0x2b8): undefined reference to `crypto_xor'
> aes_generic.c:(.text+0x2dc): undefined reference to `scatterwalk_map_and_copy'
>
> This adds an explicit 'select CRYPTO' statement the way that other
> drivers handle it.
>
> Signed-off-by: Arnd Bergmann
> Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Thnis patch is bogus. The build error is coming from the fact
that GCM is built-in but CRYPTO_ALGAPI is (presumably) only built
as a module. The patch in question does nothing to address that
AFAICS.
In fact this strikes me as a kbuild bug because CRYPTO_GCM already
selects (indirectly) CRYPTO_ALGAPI so why is this happening at all?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On Mon, Apr 18, 2016 at 03:58:59PM +0800, Baolin Wang wrote: > > That depends on the hardware engine. Some cipher hardware engines > (like xts(aes) engine) can handle the intermediate values (IV) by > themselves in one bulk block, which means we can increase the size of > the request by merging request rather than always 512 bytes and thus > increase the hardware engine processing speed. But for some other > hardware engines (like cbc(aes) engine), they can not support bulk > block, must sector by sector. So the engine drivers can select the > suitable mode to do encryption/decryption. So what is this supposed to handle, xts or cbc? > > Even with batching we should be involving the user because only the > > user knows (if anyone does) whether more data will be forthcoming. > > If this cipher engine can support bulk block encryption, the crypto > engine framework can merge requests if they are eligible > automatically. Don't need to worry about how many data will be > forthcoming. Merging is simply wrong when the data is coming in as one piece and you've just artifically broken it up, only to merge it later. If the data can be merged then it should have stayed as one piece rather than being fragmented. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v6 04/12] usb: otg-fsm: move host controller operations into usb_otg->hcd_ops
On Tue, Apr 05, 2016 at 05:05:09PM +0300, Roger Quadros wrote:
> This is to prevent missing symbol build error if OTG is
> enabled (built-in) and HCD core (CONFIG_USB) is module.
>
> Signed-off-by: Roger Quadros
Acked-by: Peter Chen
> ---
> drivers/usb/chipidea/otg_fsm.c | 7 +++
> drivers/usb/common/usb-otg-fsm.c | 15 +++
> drivers/usb/phy/phy-fsl-usb.c| 7 +++
> include/linux/usb/otg.h | 2 ++
> 4 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
> index f4e9fb5..5fdf8ca 100644
> --- a/drivers/usb/chipidea/otg_fsm.c
> +++ b/drivers/usb/chipidea/otg_fsm.c
> @@ -582,6 +582,12 @@ static struct otg_fsm_ops ci_otg_ops = {
> .start_gadget = ci_otg_start_gadget,
> };
>
> +static struct otg_hcd_ops ci_hcd_ops = {
> + .usb_bus_start_enum = usb_bus_start_enum,
> + .usb_control_msg = usb_control_msg,
> + .usb_hub_find_child = usb_hub_find_child,
> +};
> +
> int ci_otg_fsm_work(struct ci_hdrc *ci)
> {
> /*
> @@ -805,6 +811,7 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
> ci->otg.state = OTG_STATE_UNDEFINED;
> ci->otg.fsm.ops = &ci_otg_ops;
> ci->otg.fsm.dev = ci->dev;
> + ci->otg.hcd_ops = &ci_hcd_ops;
> ci->gadget.hnp_polling_support = 1;
> ci->otg.fsm.host_req_flag = devm_kzalloc(ci->dev, 1, GFP_KERNEL);
> if (!ci->otg.fsm.host_req_flag)
> diff --git a/drivers/usb/common/usb-otg-fsm.c
> b/drivers/usb/common/usb-otg-fsm.c
> index abc462c..2cb4aed 100644
> --- a/drivers/usb/common/usb-otg-fsm.c
> +++ b/drivers/usb/common/usb-otg-fsm.c
> @@ -135,11 +135,16 @@ static void otg_hnp_polling_work(struct work_struct
> *work)
> enum usb_otg_state state = otg->state;
> u8 flag;
> int retval;
> + struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
>
> if (state != OTG_STATE_A_HOST && state != OTG_STATE_B_HOST)
> return;
>
> - udev = usb_hub_find_child(otg->host->root_hub, 1);
> + if (!hcd_ops || !hcd_ops->usb_control_msg ||
> + !hcd_ops->usb_hub_find_child)
> + return;
> +
> + udev = hcd_ops->usb_hub_find_child(otg->host->root_hub, 1);
> if (!udev) {
> dev_err(otg->host->controller,
> "no usb dev connected, can't start HNP polling\n");
> @@ -148,7 +153,7 @@ static void otg_hnp_polling_work(struct work_struct *work)
>
> *fsm->host_req_flag = 0;
> /* Get host request flag from connected USB device */
> - retval = usb_control_msg(udev,
> + retval = hcd_ops->usb_control_msg(udev,
> usb_rcvctrlpipe(udev, 0),
> USB_REQ_GET_STATUS,
> USB_DIR_IN | USB_RECIP_DEVICE,
> @@ -177,7 +182,7 @@ static void otg_hnp_polling_work(struct work_struct *work)
> if (state == OTG_STATE_A_HOST) {
> /* Set b_hnp_enable */
> if (!otg->host->b_hnp_enable) {
> - retval = usb_control_msg(udev,
> + retval = hcd_ops->usb_control_msg(udev,
> usb_sndctrlpipe(udev, 0),
> USB_REQ_SET_FEATURE, 0,
> USB_DEVICE_B_HNP_ENABLE,
> @@ -256,7 +261,9 @@ static int otg_set_state(struct otg_fsm *fsm, enum
> usb_otg_state new_state)
> otg_loc_conn(otg, 0);
> otg_loc_sof(otg, 1);
> otg_set_protocol(fsm, PROTO_HOST);
> - usb_bus_start_enum(otg->host, otg->host->otg_port);
> + if (otg->hcd_ops && otg->hcd_ops->usb_bus_start_enum)
> + otg->hcd_ops->usb_bus_start_enum(otg->host,
> + otg->host->otg_port);
> otg_start_hnp_polling(fsm);
> break;
> case OTG_STATE_A_IDLE:
> diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
> index a18a2ee..39605d5 100644
> --- a/drivers/usb/phy/phy-fsl-usb.c
> +++ b/drivers/usb/phy/phy-fsl-usb.c
> @@ -792,6 +792,12 @@ static struct otg_fsm_ops fsl_otg_ops = {
> .start_gadget = fsl_otg_start_gadget,
> };
>
> +static struct otg_hcd_ops fsl_hcd_ops = {
> + .usb_bus_start_enum = usb_bus_start_enum,
> + .usb_control_msg = usb_control_msg,
> + .usb_hub_find_child = usb_hub_find_child,
> +};
> +
> /* Initialize the global variable fsl_otg_dev and request IRQ for OTG */
> static int fsl_otg_conf(struct platform_device *pdev)
> {
> @@ -821,6 +827,7 @@ static int fsl_otg_conf(struct platform_device *pdev)
> /* Set OTG state machine operations */
> fsl_otg_tc->otg.fsm.ops = &fsl_otg_ops;
> fsl_otg_tc->otg.fsm.dev = &pdev->dev;
> + fsl_otg_tc->otg.hcd_ops = &fsl_hcd_ops;
>
> /* initialize the otg structure */
> fsl_otg_tc->phy.label = DRIVER_DESC;
> diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.
Re: [PATCH] mm/memblock: move memblock_{add,reserve}_region into memblock_{add,reserve}
On 17 April 2016 at 21:14, Alexander Kuleshov wrote:
> From: 0xAX
>
> The memblock_add_region() and memblock_reserve_region do not nothing specific
> before the call of the memblock_add_range(), only print debug output.
>
> We can do the same in the memblock_add() and memblock_reserve() since both
> memblock_add_region() and memblock_reserve_region are not used by anybody
> outside of memblock.c and the memblock_{add,reserve}() have the same set of
> flags and nids.
>
> Since the memblock_add_region() and memblock_reserve_region() anyway will be
> inlined, there will not be functional changes, but will improve code
> readability
> a little.
>
> Signed-off-by: Alexander Kuleshov
Acked-by: Ard Biesheuvel
> ---
> mm/memblock.c | 28 ++--
> 1 file changed, 6 insertions(+), 22 deletions(-)
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index b570ddd..3b93daa 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -606,22 +606,14 @@ int __init_memblock memblock_add_node(phys_addr_t base,
> phys_addr_t size,
> return memblock_add_range(&memblock.memory, base, size, nid, 0);
> }
>
> -static int __init_memblock memblock_add_region(phys_addr_t base,
> - phys_addr_t size,
> - int nid,
> - unsigned long flags)
> +int __init_memblock memblock_add(phys_addr_t base, phys_addr_t size)
> {
> memblock_dbg("memblock_add: [%#016llx-%#016llx] flags %#02lx %pF\n",
> (unsigned long long)base,
> (unsigned long long)base + size - 1,
> -flags, (void *)_RET_IP_);
> -
> - return memblock_add_range(&memblock.memory, base, size, nid, flags);
> -}
> +0UL, (void *)_RET_IP_);
>
> -int __init_memblock memblock_add(phys_addr_t base, phys_addr_t size)
> -{
> - return memblock_add_region(base, size, MAX_NUMNODES, 0);
> + return memblock_add_range(&memblock.memory, base, size, MAX_NUMNODES,
> 0);
> }
>
> /**
> @@ -732,22 +724,14 @@ int __init_memblock memblock_free(phys_addr_t base,
> phys_addr_t size)
> return memblock_remove_range(&memblock.reserved, base, size);
> }
>
> -static int __init_memblock memblock_reserve_region(phys_addr_t base,
> - phys_addr_t size,
> - int nid,
> - unsigned long flags)
> +int __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
> {
> memblock_dbg("memblock_reserve: [%#016llx-%#016llx] flags %#02lx
> %pF\n",
> (unsigned long long)base,
> (unsigned long long)base + size - 1,
> -flags, (void *)_RET_IP_);
> -
> - return memblock_add_range(&memblock.reserved, base, size, nid, flags);
> -}
> +0UL, (void *)_RET_IP_);
>
> -int __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
> -{
> - return memblock_reserve_region(base, size, MAX_NUMNODES, 0);
> + return memblock_add_range(&memblock.reserved, base, size,
> MAX_NUMNODES, 0);
> }
>
> /**
> --
> 2.8.0.rc3.212.g1f992f2.dirty
>
Re: Kernel docs: muddying the waters a bit
Hi Mauro, hi kernel-doc authors, Am 12.04.2016 um 15:58 schrieb Mauro Carvalho Chehab : > Em Fri, 8 Apr 2016 17:12:27 +0200 > Markus Heiser escreveu: > >> Hi kernel-doc authors, >> >> motivated by this MT, I implemented a toolchain to migrate the kernel’s >> DocBook XML documentation to reST markup. >> >> It converts 99% of the docs well ... to gain an impression how >> kernel-docs could benefit from, visit my sphkerneldoc project page >> on github: >> >> http://return42.github.io/sphkerneldoc/ >> >> The sources available at: >> >> https://github.com/return42/sphkerneldoc >> >> The work is underway, suggestions are welcome! >> >> .. have a nice weekend .. > > Hi Markus, > > Thanks for your work. I'm basically worried about the media docbook, > with has some complexities that I was not able to figure out a way to > convert it to reST. > > So, let me pinpoint some issues that I noticed there, on a quick > look. > > The first thing I noticed is that the index doesn't match what's > there, when generated from DocBook: > https://linuxtv.org/downloads/v4l-dvb-apis/v4l2spec.html > > So, for instance, "Interfaces" is at the same level as "Input/Output". > > This sounds like an something went wrong when dealing with the title > indentation levels during the conversion. > Yes, the hierarchical structure was broken by two causes. First was, that the *chunking* was wrong and the other was, that my DocBook-XML-filter (dbxml) placed all sections and sub(-sub)-sections at the same level (direct under chapter). This was not only broken in the linux_tv book, in the other books also. Thanks for pointing and sorry that I have overlooked this (I was so much focused on on converting single elements to reST, that I not see the wood for the trees). It is now fixed, may you give it a new try. > I would also like to see the titles numbered in chapters (and, if > possible, in sections and items) and to be properly indented at the > index. BTW a few words about differences between DockBook and reST (Sphinx). With DocBook you write *books*, the protocol (the DocBook application) has no facility to *chunk* and interconnect several documents. The external ENTITY is a workaround on the SGML layer, not on XML nor on the DB-application layer. Thats the reason, why so many XML-tools don't handle this entities and many DocBook to (e.g.) reST tools are fail. With **standard** reST it is nearly the same, except there is a "include" directive on the application layer. But this directive is very simple, comparable to the C preprocessor "#include" directive. With the **superset** reST-markup of Sphinx-doc you get a the "toctree" directive, which lets you control how a document-tree should be build. http://www.sphinx-doc.org/en/stable/markup/toctree.html @Mauro: you mentioned a docutils (rst2*) experience in your mail http://marc.info/?l=linux-doc&m=145735316012094&w=2 Because the "toctree" directive -- and other directives we use -- are a part of a superset of the **standard** reST, the standard docutils (like rst2*) will not work. OK, back to your requirements: within the toctree directive you can set options like "maxdepth" and "numbered". It is a decision, how deep TOCs should go and if they should be numbered. IMO, in a HTML rendered page, with a proper navigation bar on the side, deep TOCs in the running text have no pros, they only blow up the running text and bring more scrolling with. In my sense numbering chapters make only sense in books, not in HTML pages, where you have hyperlinks. Just for demonstration, I added numbering in the linux-tv book: https://github.com/return42/sphkerneldoc/commit/468ded71f62d497ac71aead1a6d50de7ef77c3c3 May be, I will drop it later, because all reST sources are generated by a make target and I always commit the whole reST tree. As I said, it is a decision which might be made later, when the migration takes places. > Also, it seems that there's still a lot of work to do, as there are several > tables that are missing conversion, like the table for "struct > v4l2_pix_format": > > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt.html > > and the big tables at: > > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-packed-rgb.html > > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-packed-yuv.html > > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/subdev-formats.html > Yes, I marked them as TODO: https://github.com/return42/sphkerneldoc/blob/master/scripts/media.py#L262 aspect *authoring tables* (see below) > Also, some tables that are not so big like: > > https://return42.github.io/sphkerneldoc/books/linux_tv/media/v4l/pixfmt-y41p.html > > don't look nice, at least on my browser, as the "white" area is too small, > and some cells seem to be broken in two, because of the color changes in the > middle
Re: [PATCH v6 06/12] usb: otg: get rid of CONFIG_USB_OTG_FSM in favour of CONFIG_USB_OTG
On Tue, Apr 05, 2016 at 05:05:11PM +0300, Roger Quadros wrote:
> Let's use CONFIG_USB_OTG as a single config option to enable
> USB OTG and the OTG FSM. This makes things a lot less confusing.
>
> Update all users of CONFIG_USB_OTG_FSM to CONFIG_USB_OTG.
>
> Signed-off-by: Roger Quadros
> ---
> Documentation/usb/chipidea.txt | 2 +-
> drivers/usb/Makefile | 1 +
> drivers/usb/chipidea/Makefile | 2 +-
> drivers/usb/chipidea/ci.h | 2 +-
> drivers/usb/chipidea/otg_fsm.h | 2 +-
> drivers/usb/common/Makefile| 3 ++-
> drivers/usb/core/Kconfig | 8
> drivers/usb/phy/Kconfig| 2 +-
> 8 files changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt
> index 678741b..3b1f263 100644
> --- a/Documentation/usb/chipidea.txt
> +++ b/Documentation/usb/chipidea.txt
> @@ -5,7 +5,7 @@ with 2 Freescale i.MX6Q sabre SD boards.
>
> 1.1 How to enable OTG FSM in menuconfig
> ---
> -Select CONFIG_USB_OTG_FSM, rebuild kernel Image and modules.
> +Select CONFIG_USB_OTG, rebuild kernel Image and modules.
> If you want to check some internal variables for otg fsm,
> mount debugfs, there are 2 files which can show otg fsm
> variables and some controller registers value:
> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
> index dca7856..16a5b55 100644
> --- a/drivers/usb/Makefile
> +++ b/drivers/usb/Makefile
> @@ -59,5 +59,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS) += renesas_usbhs/
> obj-$(CONFIG_USB_GADGET) += gadget/
>
> obj-$(CONFIG_USB_COMMON) += common/
> +obj-$(CONFIG_USB_OTG)+= common/
Why we need to add above line?
Peter
>
> obj-$(CONFIG_USBIP_CORE) += usbip/
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 518e445..45aa24d 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -3,7 +3,7 @@ obj-$(CONFIG_USB_CHIPIDEA)+= ci_hdrc.o
> ci_hdrc-y:= core.o otg.o debug.o
> ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
> ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST) += host.o
> -ci_hdrc-$(CONFIG_USB_OTG_FSM)+= otg_fsm.o
> +ci_hdrc-$(CONFIG_USB_OTG)+= otg_fsm.o
>
> # Glue/Bridge layers go here
>
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index c523975..1a32b8c 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -406,7 +406,7 @@ static inline u32 hw_test_and_write(struct ci_hdrc *ci,
> enum ci_hw_regs reg,
> */
> static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
> {
> -#ifdef CONFIG_USB_OTG_FSM
> +#ifdef CONFIG_USB_OTG
> struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps;
>
> return ci->is_otg && ci->roles[CI_ROLE_HOST] &&
> diff --git a/drivers/usb/chipidea/otg_fsm.h b/drivers/usb/chipidea/otg_fsm.h
> index 6366fe3..2d451bb 100644
> --- a/drivers/usb/chipidea/otg_fsm.h
> +++ b/drivers/usb/chipidea/otg_fsm.h
> @@ -64,7 +64,7 @@
>
> #define TB_AIDL_BDIS (20)/* 4ms ~ 150ms, section 5.2.1 */
>
> -#if IS_ENABLED(CONFIG_USB_OTG_FSM)
> +#if IS_ENABLED(CONFIG_USB_OTG)
>
> int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci);
> int ci_otg_fsm_work(struct ci_hdrc *ci);
> diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
> index 6bbb3ec..f8f2c88 100644
> --- a/drivers/usb/common/Makefile
> +++ b/drivers/usb/common/Makefile
> @@ -6,5 +6,6 @@ obj-$(CONFIG_USB_COMMON)+= usb-common.o
> usb-common-y += common.o
> usb-common-$(CONFIG_USB_LED_TRIG) += led.o
>
> -obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
> obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
> +usbotg-y := usb-otg-fsm.o
> +obj-$(CONFIG_USB_OTG)+= usbotg.o
> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index dd28010..ae228d0 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -75,14 +75,6 @@ config USB_OTG_BLACKLIST_HUB
> and software costs by not supporting external hubs. So
> are "Embedded Hosts" that don't offer OTG support.
>
> -config USB_OTG_FSM
> - tristate "USB 2.0 OTG FSM implementation"
> - depends on USB && USB_OTG
> - select USB_PHY
> - help
> - Implements OTG Finite State Machine as specified in On-The-Go
> - and Embedded Host Supplement to the USB Revision 2.0 Specification.
> -
> config USB_ULPI_BUS
> tristate "USB ULPI PHY interface support"
> depends on USB_SUPPORT
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index c690474..06794e2 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -20,7 +20,7 @@ config AB8500_USB
>
> config FSL_USB2_OTG
> bool "Freescale USB OTG Transceiver Driver"
> - depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM
> + depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG && PM
>
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On 18 April 2016 at 16:04, Herbert Xu wrote: > On Mon, Apr 18, 2016 at 03:58:59PM +0800, Baolin Wang wrote: >> >> That depends on the hardware engine. Some cipher hardware engines >> (like xts(aes) engine) can handle the intermediate values (IV) by >> themselves in one bulk block, which means we can increase the size of >> the request by merging request rather than always 512 bytes and thus >> increase the hardware engine processing speed. But for some other >> hardware engines (like cbc(aes) engine), they can not support bulk >> block, must sector by sector. So the engine drivers can select the >> suitable mode to do encryption/decryption. > > So what is this supposed to handle, xts or cbc? As I know, now cbc engine also need to handle requests sector by sector, but for xts/ecb engine can support bulk block, which means can merge requests. > >> > Even with batching we should be involving the user because only the >> > user knows (if anyone does) whether more data will be forthcoming. >> >> If this cipher engine can support bulk block encryption, the crypto >> engine framework can merge requests if they are eligible >> automatically. Don't need to worry about how many data will be >> forthcoming. > > Merging is simply wrong when the data is coming in as one piece > and you've just artifically broken it up, only to merge it later. It will not broke it up, and it will check if the requests coming from dm-crypt can be merged together. > > If the data can be merged then it should have stayed as one piece > rather than being fragmented. Yes, usually one whole block can be merged into one request as the latency. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Baolin.wang Best Regards
Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework
Hi, Pavel Machek writes: >> >>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT) >> >> >> >> According to the spec we should always be talking about unit loads (1 >> >> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not >> >> work for SS capable ports and SS gadgets (we have quite a few of them, >> >> actually). You're missing the opportunity of charging at 900mA. >> > >> > I follow the DCP/SDP/CDP/ACA type's default current limitation and >> > user can set them what they want. >> >> no, the user CANNOT set it to what they want. If you get enumerated >> @100mA and the user just decides to set it to 2000mA, s/he could even >> melt the USB connector. The kernel _must_ prevent such cases. > > root should be allowed to do that. root should not be allowed to put user at risk. The usb connector is a path to earth ground in most (all?) desktop computers. Allowing root to put that connector in a situation where it could melt the connector and short mains should never be allowed. > Very often, you want to charge using 1.8A from an old desktop PC. if that old desktop's port is not a charging port, you shouldn't be allowed to do that. Not ever. > N900 will simply not charge from .5A. it used to with original maemo userspace/kernel. >> a) you are connected to a dedicated charger >> >> In this case, you can get up to 2000mA depending on the charger. >> >> If $this charger can give you or not 2000mA is not detectable, >> so what do charging ICs do ? They slowly increase the attached >> load accross VBUS/GND and measure VBUS value. When IC notices >> VBUS dropping bit, step back to previous load. >> >> This means you will always charger with maximum rating of DCP. >> >> Why would user change this ? More is unsafe, less is just >> stupid. > > Actually, less is not stupid. Charging li-ion battery from li-ion battery > might > be stupid. Imagine I'm on train, with device like N900 (50% battery) and > power bank > (3Ah). I'm actively using the device. If I let it charge at full current, > I'll waste > energy. If I limit current to approximately the power consumption, it will > run the > powerbank empty, first, then empty the internal battery, maximizing total > time I > can use the device. why would you waste energy ? What the charger chip would do is charge battery to maximum then just to maintenance charge from that point on. Where is energy being wasted other than normal heat dissipation ? -- balbi signature.asc Description: PGP signature
[PATCH 0/3] Add support simple-card parse jack detection via external codec
Hi, In most cases, many codecs already supports jack detection, previouslly, we need to create a customized machine driver every time. Hence, the simple-card need to support use them dynamically via parse dts file for better flexibility. Xing Zheng (3): ASoC: jack: Add a jack detect callback via codec ASoC: simple-card: Add support jack detection via codec ASoC: da7219: Add detect_jack callback in the snd_soc_codec_driver .../devicetree/bindings/sound/simple-card.txt | 17 +++ include/sound/soc.h|6 + sound/soc/codecs/da7219.c |2 + sound/soc/generic/simple-card.c| 126 +++- sound/soc/soc-jack.c |8 ++ 5 files changed, 156 insertions(+), 3 deletions(-) -- 1.7.9.5
[PATCH 1/3] ASoC: jack: Add a jack detect callback via codec
This patch add a callback when a codec have the jack detect feature.
Signed-off-by: Xing Zheng
---
include/sound/soc.h |6 ++
sound/soc/soc-jack.c |8
2 files changed, 14 insertions(+)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 02b4a21..ff105a4 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -547,6 +547,10 @@ static inline void snd_soc_jack_free_gpios(struct
snd_soc_jack *jack, int count,
}
#endif
+/* init jack detect via codec */
+void snd_soc_jack_codec_detect(struct snd_soc_codec *codec,
+ struct snd_soc_jack *jack);
+
/* codec register bit access */
int snd_soc_update_bits(struct snd_soc_codec *codec, unsigned int reg,
unsigned int mask, unsigned int value);
@@ -920,6 +924,8 @@ struct snd_soc_codec_driver {
enum snd_soc_dapm_type, int);
bool ignore_pmdown_time; /* Doesn't benefit from pmdown delay */
+
+ void (*detect_jack)(struct snd_soc_codec *codec, struct snd_soc_jack
*jack);
};
/* SoC platform interface */
diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c
index fbaa1bb..e292fb4 100644
--- a/sound/soc/soc-jack.c
+++ b/sound/soc/soc-jack.c
@@ -436,3 +436,11 @@ void snd_soc_jack_free_gpios(struct snd_soc_jack *jack,
int count,
}
EXPORT_SYMBOL_GPL(snd_soc_jack_free_gpios);
#endif /* CONFIG_GPIOLIB */
+
+void snd_soc_jack_codec_detect(struct snd_soc_codec *codec,
+ struct snd_soc_jack *jack)
+{
+ if (codec && codec->driver && codec->driver->detect_jack)
+ codec->driver->detect_jack(codec, jack);
+}
+EXPORT_SYMBOL_GPL(snd_soc_jack_codec_detect);
--
1.7.9.5
[PATCH 3/3] ASoC: da7219: Add detect_jack callback in the snd_soc_codec_driver
This patch tell soc-jack that this codec supports jack detection.
Signed-off-by: Xing Zheng
---
sound/soc/codecs/da7219.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
index 81c0708..5a8ff1e 100644
--- a/sound/soc/codecs/da7219.c
+++ b/sound/soc/codecs/da7219.c
@@ -1767,6 +1767,8 @@ static struct snd_soc_codec_driver soc_codec_dev_da7219 =
{
.num_dapm_widgets = ARRAY_SIZE(da7219_dapm_widgets),
.dapm_routes= da7219_audio_map,
.num_dapm_routes= ARRAY_SIZE(da7219_audio_map),
+
+ .detect_jack= da7219_aad_jack_det,
};
--
1.7.9.5
[PATCH 2/3] ASoC: simple-card: Add support jack detection via codec
In most cases, many codecs already supports jack detection, previouslly,
we need to create a customized machine driver every time.
Hence, the simple-card need to support use them dynamically via parse dts
file for better flexibility.
Signed-off-by: Xing Zheng
---
.../devicetree/bindings/sound/simple-card.txt | 17 +++
sound/soc/generic/simple-card.c| 126 +++-
2 files changed, 140 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt
b/Documentation/devicetree/bindings/sound/simple-card.txt
index cf3979e..d25c8eb 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -22,6 +22,23 @@ Optional properties:
headphones are attached.
- simple-audio-card,mic-det-gpio : Reference to GPIO that signals when
a microphone is attached.
+- simple-audio-card,codec-jack : A list of the codec supports jack
detection.
+ The jack types which are supported
refer to include/sound/jack.h.
+ All of the jack types:
+ "JACK_HEADPHONE",
+ "JACK_MICROPHONE",
+ "JACK_HEADSET",
+ "JACK_LINEOUT",
+ "JACK_MECHANICAL",
+ "JACK_VIDEOOUT",
+ "JACK_AVOUT",
+ "JACK_LINEIN",
+ "JACK_BTN_0",
+ "JACK_BTN_1",
+ "JACK_BTN_2",
+ "JACK_BTN_3",
+ "JACK_BTN_4",
+ "JACK_BTN_5".
Optional subnodes:
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 2389ab4..bc61022 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -33,12 +33,35 @@ struct simple_card_data {
int gpio_hp_det_invert;
int gpio_mic_det;
int gpio_mic_det_invert;
+ struct simple_codecs_jack {
+ int jack_det;
+ int jack_types;
+ struct snd_soc_jack codec_jack;
+ } *codec_det_jack;
struct snd_soc_dai_link dai_link[]; /* dynamically allocated */
};
#define simple_priv_to_dev(priv) ((priv)->snd_card.dev)
#define simple_priv_to_link(priv, i) ((priv)->snd_card.dai_link + i)
#define simple_priv_to_props(priv, i) ((priv)->dai_props + i)
+#define simple_priv_to_codecdetjack(priv, i) ((priv)->codec_det_jack + i)
+
+static const char * const jack_types_list[] = {
+ "JACK_HEADPHONE",
+ "JACK_MICROPHONE",
+ "JACK_HEADSET",
+ "JACK_LINEOUT",
+ "JACK_MECHANICAL",
+ "JACK_VIDEOOUT",
+ "JACK_AVOUT",
+ "JACK_LINEIN",
+ "JACK_BTN_0",
+ "JACK_BTN_1",
+ "JACK_BTN_2",
+ "JACK_BTN_3",
+ "JACK_BTN_4",
+ "JACK_BTN_5",
+};
static int asoc_simple_card_startup(struct snd_pcm_substream *substream)
{
@@ -136,6 +159,8 @@ static struct snd_soc_jack_gpio simple_card_mic_jack_gpio =
{
.debounce_time = 150,
};
+static struct snd_soc_jack simple_card_codecs_jack;
+
static int __asoc_simple_card_dai_init(struct snd_soc_dai *dai,
struct asoc_simple_dai *set)
{
@@ -173,9 +198,12 @@ static int asoc_simple_card_dai_init(struct
snd_soc_pcm_runtime *rtd)
struct snd_soc_dai *codec = rtd->codec_dai;
struct snd_soc_dai *cpu = rtd->cpu_dai;
struct simple_dai_props *dai_props;
+ struct simple_codecs_jack *codec_det_jack;
int ret;
dai_props = &priv->dai_props[rtd->num];
+ codec_det_jack = &priv->codec_det_jack[rtd->num];
+
ret = __asoc_simple_card_dai_init(codec, &dai_props->codec_dai);
if (ret < 0)
return ret;
@@ -208,6 +236,80 @@ static int asoc_simple_card_dai_init(struct
snd_soc_pcm_runtime *rtd)
snd_soc_jack_add_gpios(&simple_card_mic_jack, 1,
&simple_card_mic_jack_gpio);
}
+
+ if (codec_det_jack->jack_det) {
+ ret = snd_soc_card_jack_new(rtd->card, "Simple-card Codec Jack",
+ codec_det_jack->jack_types,
+ &simple_card_codecs_jack, NULL, 0);
+ if (ret) {
+ dev_err(rtd->card->dev, "New Simple-card Codec Jack
failed! (%d)\n", ret);
+ return ret;
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On Mon, Apr 18, 2016 at 04:14:48PM +0800, Baolin Wang wrote: > On 18 April 2016 at 16:04, Herbert Xu wrote: > > On Mon, Apr 18, 2016 at 03:58:59PM +0800, Baolin Wang wrote: > >> > >> That depends on the hardware engine. Some cipher hardware engines > >> (like xts(aes) engine) can handle the intermediate values (IV) by > >> themselves in one bulk block, which means we can increase the size of > >> the request by merging request rather than always 512 bytes and thus > >> increase the hardware engine processing speed. But for some other > >> hardware engines (like cbc(aes) engine), they can not support bulk > >> block, must sector by sector. So the engine drivers can select the > >> suitable mode to do encryption/decryption. > > > > So what is this supposed to handle, xts or cbc? > > As I know, now cbc engine also need to handle requests sector by > sector, but for xts/ecb engine can support bulk block, which means can > merge requests. If it's just xts then why can't dm-crypt merge it and send a single request? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework
Hi, Pavel Machek writes: > Hi! > >> > It's your HW :-) You tell me if it's really necessary. But, hey, if you >> > get enumerated @500mA, this is the host telling you it _CAN_ give you >> > 500mA. In that case, why wouldn't you ? > > Dunno, perhaps not to drain battery in host too quickly? > Or perhaps you are charging from external battery? > >> >>> why RW ? Who's going to use these ? Also, you're not documenting this >> >>> new sysfs file. >> >> >> >> Cause we have show and store operation for SDP type. If users want to >> >> know or set the SDP current, they can use the sysfs file. >> >> I'll add the documentation for it. >> > >> > but why would the user change it ? Here's the thing: you have a few >> > posibilities for this: >> > >> > a) you are connected to a dedicated charger >> > >> > In this case, you can get up to 2000mA depending on the charger. >> > >> > If $this charger can give you or not 2000mA is not detectable, >> > so what do charging ICs do ? They slowly increase the attached >> > load accross VBUS/GND and measure VBUS value. When IC notices >> > VBUS dropping bit, step back to previous load. >> > >> > This means you will always charger with maximum rating of DCP. >> > >> > Why would user change this ? More is unsafe, less is just >> > stupid. > > Less is not neccessarily stupid. First, it is useful for debugging, second, > you > don't know how much this charger can give you. You measured you can get 1.8A, > but the note on the charger says 1.5A. You may want to go with 1.5A. > > Also, there are several incompatible standards for detecting > "dedicated charger". IIRC iPhone has different one from iPad. So it is > quite important to be able to control this manually. manually ??? Hell no! Charger IC should be able to do this no problem. I would be surprised if there's any charger IC out there which blindly connects a 1.8A load from the start. What these ICs do is that they slowly increment the load and check voltage level. They'll continue to do that up to the maximum you listed (1.8A, let's say). As soon as voltage drops a bit, charger IC knows that it use previous load. >> > d) you are connected to a standard port and get enumerated with your >> > 100mA configuration. >> > >> > you *know* 100mA is okay. So you connect a 100mA load and get it >> > over with. >> > >> > This means you will always charger with maximum rating for this >> > SDP. >> > >> > Why would user change this ? More is unsafe, less is just >> > stupid. > > I've needed to override 100mA default many times. Maybe it is unsafe, > but it is useful. still unsafe. If you really wanna do that, you're welcome to removing safety margins from your own kernel, but we're definitely not going to ship this to millions of users. > (And with USB 5V connected directly to pretty beefy PC power supply... > it is sometimes safer than it looks). you're not considering the thermal dissipation on the USB connector itself. Many of them might not use good metals because they assume the maximum power dissipated is 500mA * 5V = 2.5W. If you try to draw more, you could, literally, melt the connector. -- balbi signature.asc Description: PGP signature
[PATCH] tracing: Don't use the address of the buffer array name in copy_from_user
Hi, all, >From 7dbacb179a4d5f9ac9d7e1b3733664b3b0fe23ae Mon Sep 17 00:00:00 2001 From: Wang Xiaoqiang Date: Mon, 18 Apr 2016 14:58:15 +0800 Subject: [PATCH] tracing: Don't use the address of the buffer array name in copy_from_user Fix the problem as follows: ... char buf[64]; ... if (copy_from_user(&buf, ubuf, cnt)) ... Even though the value of "&buf" equals "buf", but there is no need to get the address of the "buf" again. Use "buf" replace "&buf". Signed-off-by: Wang Xiaoqiang --- kernel/trace/trace.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index a2f0b9f..422ab57 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -3658,7 +3658,7 @@ tracing_trace_options_write(struct file *filp, const char __user *ubuf, if (cnt >= sizeof(buf)) return -EINVAL; - if (copy_from_user(&buf, ubuf, cnt)) + if (copy_from_user(buf, ubuf, cnt)) return -EFAULT; buf[cnt] = 0; @@ -4474,7 +4474,7 @@ tracing_set_trace_write(struct file *filp, const char __user *ubuf, if (cnt > MAX_TRACER_SIZE) cnt = MAX_TRACER_SIZE; - if (copy_from_user(&buf, ubuf, cnt)) + if (copy_from_user(buf, ubuf, cnt)) return -EFAULT; buf[cnt] = 0; @@ -5264,7 +5264,7 @@ static ssize_t tracing_clock_write(struct file *filp, const char __user *ubuf, if (cnt >= sizeof(buf)) return -EINVAL; - if (copy_from_user(&buf, ubuf, cnt)) + if (copy_from_user(buf, ubuf, cnt)) return -EFAULT; buf[cnt] = 0; -- 2.1.4
Re: [PATCH 3/7] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Decoder Driver
Hi Hans,
On Mon, 2016-04-18 at 09:32 +0200, Hans Verkuil wrote:
> On 04/18/2016 07:40 AM, tiffany lin wrote:
> >
> > snipped.
> >
> >>> +
> >>> +void mtk_vcodec_dec_set_default_params(struct mtk_vcodec_ctx *ctx)
> >>> +{
> >>> + struct mtk_q_data *q_data;
> >>> +
> >>> + ctx->m2m_ctx->q_lock = &ctx->dev->dev_mutex;
> >>> + ctx->fh.m2m_ctx = ctx->m2m_ctx;
> >>> + ctx->fh.ctrl_handler = &ctx->ctrl_hdl;
> >>> + INIT_WORK(&ctx->decode_work, mtk_vdec_worker);
> >>> +
> >>> + q_data = &ctx->q_data[MTK_Q_DATA_SRC];
> >>> + memset(q_data, 0, sizeof(struct mtk_q_data));
> >>> + q_data->visible_width = DFT_CFG_WIDTH;
> >>> + q_data->visible_height = DFT_CFG_HEIGHT;
> >>> + q_data->fmt = &mtk_video_formats[OUT_FMT_IDX];
> >>> + q_data->colorspace = V4L2_COLORSPACE_REC709;
> >>> + q_data->field = V4L2_FIELD_NONE;
> >>> + ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
> >>> + DFT_CFG_WIDTH * DFT_CFG_HEIGHT;
> >>> + ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] = 0;
> >>> +
> >>> +
> >>> + q_data = &ctx->q_data[MTK_Q_DATA_DST];
> >>> + memset(q_data, 0, sizeof(struct mtk_q_data));
> >>> + q_data->visible_width = DFT_CFG_WIDTH;
> >>> + q_data->visible_height = DFT_CFG_HEIGHT;
> >>> + q_data->coded_width = DFT_CFG_WIDTH;
> >>> + q_data->coded_height = DFT_CFG_HEIGHT;
> >>> + q_data->colorspace = V4L2_COLORSPACE_REC709;
> >>> + q_data->field = V4L2_FIELD_NONE;
> >>> +
> >>> + q_data->fmt = &mtk_video_formats[CAP_FMT_IDX];
> >>> +
> >>> + v4l_bound_align_image(&q_data->coded_width,
> >>> + MTK_VDEC_MIN_W,
> >>> + MTK_VDEC_MAX_W, 4,
> >>> + &q_data->coded_height,
> >>> + MTK_VDEC_MIN_H,
> >>> + MTK_VDEC_MAX_H, 5, 6);
> >>> +
> >>> + q_data->sizeimage[0] = q_data->coded_width * q_data->coded_height;
> >>> + q_data->bytesperline[0] = q_data->coded_width;
> >>> + q_data->sizeimage[1] = q_data->sizeimage[0] / 2;
> >>> + q_data->bytesperline[1] = q_data->coded_width;
> >>> +
> >>> +}
> >>> +
> >>> +static int vidioc_vdec_streamon(struct file *file, void *priv,
> >>> + enum v4l2_buf_type type)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +
> >>> + mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
> >>> +
> >>> + return v4l2_m2m_streamon(file, ctx->m2m_ctx, type);
> >>> +}
> >>> +
> >>> +static int vidioc_vdec_streamoff(struct file *file, void *priv,
> >>> + enum v4l2_buf_type type)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +
> >>> + mtk_v4l2_debug(3, "[%d] (%d)", ctx->idx, type);
> >>> + return v4l2_m2m_streamoff(file, ctx->m2m_ctx, type);
> >>> +}
> >>> +
> >>> +static int vidioc_vdec_reqbufs(struct file *file, void *priv,
> >>> +struct v4l2_requestbuffers *reqbufs)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> + int ret;
> >>> +
> >>> + mtk_v4l2_debug(3, "[%d] (%d) count=%d", ctx->idx,
> >>> + reqbufs->type, reqbufs->count);
> >>> + ret = v4l2_m2m_reqbufs(file, ctx->m2m_ctx, reqbufs);
> >>> +
> >>> + return ret;
> >>> +}
> >>
> >> Please use the v4l2_m2m_ioctl_* helper functions were applicable.
> >>
> >
> >
> >
> > snipped.
> >>> +static unsigned int fops_vcodec_poll(struct file *file,
> >>> + struct poll_table_struct *wait)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
> >>> + struct mtk_vcodec_dev *dev = ctx->dev;
> >>> + int ret;
> >>> +
> >>> + mutex_lock(&dev->dev_mutex);
> >>> + ret = v4l2_m2m_poll(file, ctx->m2m_ctx, wait);
> >>> + mutex_unlock(&dev->dev_mutex);
> >>> +
> >>> + return ret;
> >>> +}
> >>> +
> >>> +static int fops_vcodec_mmap(struct file *file, struct vm_area_struct
> >>> *vma)
> >>> +{
> >>> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(file->private_data);
> >>> +
> >>> + return v4l2_m2m_mmap(file, ctx->m2m_ctx, vma);
> >>> +}
> >>> +
> >>> +static const struct v4l2_file_operations mtk_vcodec_fops = {
> >>> + .owner = THIS_MODULE,
> >>> + .open = fops_vcodec_open,
> >>> + .release= fops_vcodec_release,
> >>> + .poll = fops_vcodec_poll,
> >>> + .unlocked_ioctl = video_ioctl2,
> >>> + .mmap = fops_vcodec_mmap,
> >>
> >> You should be able to use the v4l2_m2m_fop helper functions for poll and
> >> mmap.
> >>
> >
> > Hi Hans,
> >
> > We are plaining to remove m2m framework in th feature, although we think
>
> Remove it for just the decoder driver or both encoder and decoder?
>
Remove it from decoder driver.
> > it is easy to use and could save a lot of code similar to what m2m
> > framework implemented and reduce code size.
> > The main reason is that in v4l2_m2m_try_schedule, it required that at
> > least one output buffer and one capture buffer to run device_run.
> > We want to sta
Re: [PATCH 2/3] sched: Correctly handle nohz ticks cpu load accounting
On Wed, Apr 13, 2016 at 03:56:51PM +0200, Frederic Weisbecker wrote:
> @@ -4524,12 +4523,12 @@ decay_load_missed(unsigned long load, unsigned long
> missed_updates, int idx)
> * load[i]_n = (1 - 1/2^i)^n * load[i]_0
> *
> * see decay_load_misses(). For NOHZ_FULL we get to subtract and add the
> extra
> - * term. See the @active paramter.
> + * term.
> */
> -static void __cpu_load_update(struct rq *this_rq, unsigned long this_load,
> - unsigned long pending_updates, int active)
> +static void cpu_load_update(struct rq *this_rq, unsigned long this_load,
> + unsigned long pending_updates)
> {
> - unsigned long tickless_load = active ? this_rq->cpu_load[0] : 0;
> + unsigned long tickless_load = this_rq->cpu_load[0];
Hello,
Good for my humble code to be fixed so we can write it like this here.
> @@ -4618,26 +4617,56 @@ static void cpu_load_update_idle(struct rq *this_rq)
> if (weighted_cpuload(cpu_of(this_rq)))
> return;
>
> - __cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), 0, 0);
> + cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), 0);
> }
>
> /*
> - * Called from tick_nohz_idle_exit() -- try and fix up the ticks we missed.
> + * Record CPU load on nohz entry so we know the tickless load to account
> + * on nohz exit. cpu_load[0] happens then to be updated more frequently
> + * than other cpu_load[idx] but it should be fine as cpu_load readers
> + * shouldn't rely into synchronized cpu_load[*] updates.
> */
> -void cpu_load_update_nohz(int active)
> +void cpu_load_update_nohz_start(void)
> {
> struct rq *this_rq = this_rq();
> +
> + /*
> + * This is all lockless but should be fine. If weighted_cpuload changes
> + * concurrently we'll exit nohz. And cpu_load write can race with
> + * cpu_load_update_idle() but both updater would be writing the same.
> + */
> + this_rq->cpu_load[0] = weighted_cpuload(cpu_of(this_rq));
Like it.
> +/*
> + * Account the tickless load in the end of a nohz frame.
> + */
> +void cpu_load_update_nohz_stop(void)
> +{
> unsigned long curr_jiffies = READ_ONCE(jiffies);
> - unsigned long load = active ? weighted_cpuload(cpu_of(this_rq)) : 0;
> + struct rq *this_rq = this_rq();
> + unsigned long load;
>
> if (curr_jiffies == this_rq->last_load_update_tick)
> return;
>
> + load = weighted_cpuload(cpu_of(this_rq));
Like it.
> @@ -4645,11 +4674,11 @@ void cpu_load_update_nohz(int active)
> void cpu_load_update_active(struct rq *this_rq)
> {
> unsigned long load = weighted_cpuload(cpu_of(this_rq));
> - /*
> - * See the mess around cpu_load_update_idle() / cpu_load_update_nohz().
> - */
> - this_rq->last_load_update_tick = jiffies;
> - __cpu_load_update(this_rq, load, 1, 1);
> +
> + if (tick_nohz_tick_stopped())
> + cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), load);
> + else
> + cpu_load_update_periodic(this_rq, load);
Oh! We have missed it until now. Terrible.. :-(
Thank you,
Byungchul
Re: [PATCH v3 1/6] rtmutex: Deboost before waking up the top waiter
On Thu, 14 Apr 2016, Xunlei Pang wrote: > We should deboost before waking the high-prio task such that > we don't run two tasks with the 'same' priority. No. This is fundamentaly broken. T1 (prio 0) lock(X) --> preemption T2 (prio 10)lock(X) boost(T1) schedule() T1 (prio 10)unlock(X) deboost() (prio 0) --> preemption T3 (prio 5) Classic priority inversion enabled by a mechanism to avoid it. Brilliant stuff. Thanks, tglx
Re: [PATCH 1/2] pinctrl: Add Oxford Semiconductor OXNAS pinctrl and gpio driver
On 04/13/2016 03:42 PM, Linus Walleij wrote:
> On Sun, Apr 3, 2016 at 3:26 PM, Neil Armstrong
> wrote:
>
>> Add pinctrl and gpio control support to Oxford Semiconductor OXNAS SoC
>> Family.
>> This version supports the ARM926EJ-S based OX810SE SoC with 34 IO pins.
>>
>> Signed-off-by: Neil Armstrong
>
> Starting to look very nice :)
>
>> +static inline struct oxnas_gpio_bank *irqd_to_bank(struct irq_data *d)
>> +{
>> + return gpiochip_get_data(irq_data_get_irq_chip_data(d));
>> +}
>
> Do you really need to wrap this call? Seems like pointless layer of
> abstraction to me.
Sure, I'll remove it.
>> + if (of_parse_phandle_with_fixed_args(np, "gpio-ranges",
>> +3, 0, &pinspec)) {
>> + dev_err(&pdev->dev, "gpio-ranges property not found\n");
>> + return -EINVAL;
>> + }
>> +
>> + id = pinspec.args[1] / PINS_PER_BANK;
>> + ngpios = pinspec.args[2];
>> +
>> + if (id >= ARRAY_SIZE(oxnas_gpio_banks)) {
>> + dev_err(&pdev->dev, "invalid gpio-ranges base arg\n");
>> + return -EINVAL;
>> + }
>> +
>> + if (ngpios > PINS_PER_BANK) {
>> + dev_err(&pdev->dev, "invalid gpio-ranges count arg\n");
>> + return -EINVAL;
>> + }
>> +
>> + bank = &oxnas_gpio_banks[id];
>
> This feels a bit hackish but I guess that is how we have to do things
> then :/
It seems I'll need to stick with this for the moment :/
>> +static int __init oxnas_gpio_register(void)
>> +{
>> + return platform_driver_register(&oxnas_gpio_driver);
>> +}
>> +arch_initcall(oxnas_gpio_register);
>> +
>> +static int __init oxnas_pinctrl_register(void)
>> +{
>> + return platform_driver_register(&oxnas_pinctrl_driver);
>> +}
>> +arch_initcall(oxnas_pinctrl_register);
>
> Why do these have to be arch_initcall()?
>
> I'm not very happy with anything below subsys_initcall()
> and others prefer that you have only device_initcall().
>
> I need some rationale. Sorry if I already asked...
Actually, arch_initcall seems the best level to permit further device to get
interrupts from these gpio controllers, AFAIK quite all the upstream pinctrl
driver uses arch_ or subsys_.
> Yours,
> Linus Walleij
>
Thanks,
Neil
RE: [PATCH v10 1/4] gadget: Introduce the usb charger framework
Hi
> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Monday, April 11, 2016 7:15 PM
> To: Jun Li
> Cc: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org; peter.c...@freescale.com;
> st...@rowland.harvard.edu; r.bald...@samsung.com;
> yoshihiro.shimoda...@renesas.com; lee.jo...@linaro.org; broo...@kernel.org;
> ckee...@opensource.wolfsonmicro.com; patc...@opensource.wolfsonmicro.com;
> linux...@vger.kernel.org; linux-...@vger.kernel.org; device-
> mainlin...@lists.linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework
>
> Hi Jun,
>
> Sorry for late reply.
>
> >> >> >> >> +/*
> >> >> >> >> + * usb_charger_detect_type() - detect the charger type
> manually.
> >> >> >> >> + * @uchger - usb charger device
> >> >> >> >> + *
> >> >> >> >> + * Note: You should ensure you need to detect the charger
> >> >> >> >> +type manually on your
> >> >> >> >> + * platform.
> >> >> >> >> + * You should call it at the right gadget state to avoid
> >> >> >> >> +affecting gadget
> >> >> >> >> + * enumeration.
> >> >> >> >> + */
> >> >> >> >> +int usb_charger_detect_type(struct usb_charger *uchger) {
> >> >> >> >> + enum usb_charger_type type;
> >> >> >> >> +
> >> >> >> >> + if (WARN(!uchger->charger_detect,
> >> >> >> >> + "charger detection method should not be NULL"))
> >> >> >> >> + return -EINVAL;
> >> >> >> >> +
> >> >> >> >> + type = uchger->charger_detect(uchger);
> >> >> >> >> +
> >> >> >> >> + mutex_lock(&uchger->lock);
> >> >> >> >> + uchger->type = type;
> >> >> >> >> + mutex_unlock(&uchger->lock);
> >> >> >> >> +
> >> >> >> >> + return 0;
> >> >> >> >> +}
> >> >> >> >> +EXPORT_SYMBOL_GPL(usb_charger_detect_type);
> >> >> >> >
> >> >> >> > I still recommend have a central place to call
> >> >> >> > usb_charger_detect_type() to cover real charger detection
> >> >> >> > instead of leaving this question open to diff users. This can
> >> >> >> > be done after vbus-on is detected and before do gadget
> >> >> >> > connect. I don't think this
> >> >> >> will make your framework complicated.
> >> >> >>
> >> >> >> This API is used for detecting the charger type manually
> >> >> >> (software charger detection), so if user's udc driver is needed
> >> >> >> to do this, then they can issue it at their right place to make
> it more flexible.
> >> >> >> But let us see other people's suggestion. Thanks.
> >> >> >
> >> >> > Ok, actually this API can be used for what ever charger
> >> >> > detection type, user can implement any method(manual detection,
> >> >> > directly read result from some HW...what ever) in
> >> >> > uchger->charger_detect(), target is
> >> >>
> >> >> But reading result from some HW dose not means *detect*, actually
> >> >> is
> >> *get*.
> >> >> We can not mix them together with the different semantics.
> >> >
> >> > It doesn’t matter here, you already define the _get_ API for just
> >> > read the charger type from the saved value(uchger->type), so we can
> >> > think the API to make uchger->type from UNKNOW to ONE KNOWN type is
> >> > *detect*, because we don't need 2 separate API one for *get* type
> >> > from HW and another one for *detect* from HW, only one API involve
> >> > HW access
> >> is enough.
> >>
> >> But another issue is some users may need to get the charger type from
> >> power supply by "power_supply_get_property()" function, we need to
> >> integrate with the power supply things in the usb charger framework,
> >> not user to implement that.
> >
> > Why this user(your case) can't put the charger type get by
> > "power_supply_get_property()" in its uchger->charger_detect(), any
> > special reason prevent you doing it? I am not sure if this case is
> > very common, even if it is, you also can put it in
> > usb_charger_detect_type()
> >
> > usb_charger_detect_type()
> > {
> > If can get from power_supply_get_property()
> > ...
> > else if uchger->charger_detect
> > uchger->charger_detect();
> > ...
> > }
>
> If user want to implement above method, they need to get the
> 'power_supply' structure to do this action, which maybe can not get in
> some contexts. So we need to integrate with the power supply things to
> avoid this situation. IIRC, Felipe suggested me to flesh out the charger
> getting method.
>
Okay, then I agree with you to let user do that with more flexibility,
I tried to enable usb charger detection on one NXP i.mx platform based on
this framework, works fine, thanks!
Li Jun
> Hi Felipe, what do you think of Jun's suggestion? Thanks.
>
> >
> > I don't know if most design of usb charger detection now days is as
> > easy as your PMIC for software(HW does the whole detection process and
> > prevent the vbus generation until detection has completed), anyway if
> > your framework can guarantee the detection pro
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On 18 April 2016 at 16:17, Herbert Xu wrote: > On Mon, Apr 18, 2016 at 04:14:48PM +0800, Baolin Wang wrote: >> On 18 April 2016 at 16:04, Herbert Xu wrote: >> > On Mon, Apr 18, 2016 at 03:58:59PM +0800, Baolin Wang wrote: >> >> >> >> That depends on the hardware engine. Some cipher hardware engines >> >> (like xts(aes) engine) can handle the intermediate values (IV) by >> >> themselves in one bulk block, which means we can increase the size of >> >> the request by merging request rather than always 512 bytes and thus >> >> increase the hardware engine processing speed. But for some other >> >> hardware engines (like cbc(aes) engine), they can not support bulk >> >> block, must sector by sector. So the engine drivers can select the >> >> suitable mode to do encryption/decryption. >> > >> > So what is this supposed to handle, xts or cbc? >> >> As I know, now cbc engine also need to handle requests sector by >> sector, but for xts/ecb engine can support bulk block, which means can >> merge requests. > > If it's just xts then why can't dm-crypt merge it and send a single > request? What I meaning is if the xts engine can support bulk block, then the engine driver can select bulk mode to do encryption, but if their xts engine can not support bulk mode, which depends on hardware design, the engine driver can not select bulk mode. So the dm-crypt can not know what will be selected by the engine driver, it can not send one bulk block each time. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Baolin.wang Best Regards
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On Mon, Apr 18, 2016 at 04:28:46PM +0800, Baolin Wang wrote: > > What I meaning is if the xts engine can support bulk block, then the > engine driver can select bulk mode to do encryption, but if their xts > engine can not support bulk mode, which depends on hardware design, > the engine driver can not select bulk mode. So the dm-crypt can not > know what will be selected by the engine driver, it can not send one > bulk block each time. Why can't the xts code just break it up if it can't handle it? You want to postpone splitting as much as possible. Even if the underlying xts code couldn't handle it, it would still make sense for the crypto API to see the request in one piece. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 7/8] pci: spread interrupt vectors in pci_alloc_irq_vectors
On Fri, 15 Apr 2016, Christoph Hellwig wrote:
> Set the affinity_mask before allocating vectors. And for now we also
> need a little hack after allocation, hopefully someone smarter than me
> can move this into the core code.
>
>
> + /* XXX: this should really move into the core IRQ allocation code.. */
> + if (vecs > 1) {
> + for (i = 0; i < vecs; i++)
> + irq_program_affinity(irqs[i]);
No. We don't want to do that at allocation time. The problem here is that we
set the IRQF_NOBALANCING flag for the allocated interrupts and therefor the
affinity is not set from request_irq(). We'll fix it there.
Thanks,
tglx
Re: [PATCHv2]brd: set max_discard_sectors properly
On Sat, Apr 16, 2016 at 3:50 AM, Christoph Hellwig wrote: >> - blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX); >> + blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX >> 9); > > Shouldn't we fix the issue by capping to UINT_MAX >> 9 inside > blk_queue_max_discard_sectors? That way we'll prevent against having > issues like this in any other driver as well. Thanks Christoph, make sense to me, will rework it to this way. Regards, Jack
[PATCH] efi: ARM: avoid warning about phys_addr_t cast
memblock_remove() takes a phys_addr_t, which may be narrower than 64 bits,
causing a harmless warning:
drivers/firmware/efi/arm-init.c: In function 'reserve_regions':
include/linux/kernel.h:29:20: error: large integer implicitly truncated to
unsigned type [-Werror=overflow]
#define ULLONG_MAX (~0ULL)
^
drivers/firmware/efi/arm-init.c:152:21: note: in expansion of macro 'ULLONG_MAX'
memblock_remove(0, ULLONG_MAX);
This adds an explicit typecast to avoid the warning
Signed-off-by: Arnd Bergmann
Fixes: 500899c2cc3e ("efi: ARM/arm64: ignore DT memory nodes instead of
removing them")
---
drivers/firmware/efi/arm-init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 434dd6065935..fac567c3b66a 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -149,7 +149,7 @@ static __init void reserve_regions(void)
* uses its own memory map instead.
*/
memblock_dump_all();
- memblock_remove(0, ULLONG_MAX);
+ memblock_remove(0, (phys_addr_t)ULLONG_MAX);
for_each_efi_memory_desc(&memmap, md) {
paddr = md->phys_addr;
--
2.7.0
Re: [PATCH v2] watchdog: add driver for StreamLabs USB watchdog device
On Mon, 2016-04-18 at 03:53 +0100, Alexey Klimov wrote:
> This patch creates new driver that supports StreamLabs usb watchdog
> device. This device plugs into 9-pin usb header and connects to
> reset pin and reset button on common PC.
>
> USB commands used to communicate with device were reverse
> engineered using usbmon.
Almost. I see only one issue.
> +struct streamlabs_wdt {
> + struct watchdog_device wdt_dev;
> + struct usb_interface *intf;
> +
> + struct mutex lock;
> + u8 buffer[BUFFER_LENGTH];
That is wrong.
> +};
> +
[..]
> +static int usb_streamlabs_wdt_command(struct watchdog_device *wdt_dev, u16
> cmd)
> +{
> + struct streamlabs_wdt *streamlabs_wdt = watchdog_get_drvdata(wdt_dev);
> + struct usb_device *usbdev;
> + int retval;
> + int size;
> + unsigned long timeout_msec;
> +
> + int retry_counter = 10; /* how many times to re-send stop cmd */
> +
> + mutex_lock(&streamlabs_wdt->lock);
> +
> + if (unlikely(!streamlabs_wdt->intf)) {
> + mutex_unlock(&streamlabs_wdt->lock);
> + return -ENODEV;
> + }
> +
> + usbdev = interface_to_usbdev(streamlabs_wdt->intf);
> + timeout_msec = wdt_dev->timeout * MSEC_PER_SEC;
> +
> + do {
> + usb_streamlabs_wdt_prepare_buf((u16 *) streamlabs_wdt->buffer,
> + cmd, timeout_msec);
> + /* send command to watchdog */
> + retval = usb_interrupt_msg(usbdev, usb_sndintpipe(usbdev, 0x02),
> + streamlabs_wdt->buffer, BUFFER_TRANSFER_LENGTH,
Because of this line.
The problem is subtle. Your buffer and your lock share a cacheline.
On some architecture the cache is not consistent with respect to DMA.
On them cachelines holding a buffer for DMA need to be flushed to RAM
and invalidated and you may read from them only after DMA has finished.
Thus you may have prepared a cacheline for DMA but somebody tries taking
the lock. Then the cacheline with the lock is read from RAM. If that
happens before you finish the DMA the data resulting from DMA is lost.
The fix is to allocate the buffer with its own allocation. The VM
subsystem makes sure separate allocation don't share cachelines.
That is the long explanation for what I mean when I say that you violate
the DMA rules.
Regards
Oliver
Re: [PATCH] efi: ARM: avoid warning about phys_addr_t cast
On 18 April 2016 at 10:34, Arnd Bergmann wrote:
> memblock_remove() takes a phys_addr_t, which may be narrower than 64 bits,
> causing a harmless warning:
>
> drivers/firmware/efi/arm-init.c: In function 'reserve_regions':
> include/linux/kernel.h:29:20: error: large integer implicitly truncated to
> unsigned type [-Werror=overflow]
> #define ULLONG_MAX (~0ULL)
> ^
> drivers/firmware/efi/arm-init.c:152:21: note: in expansion of macro
> 'ULLONG_MAX'
> memblock_remove(0, ULLONG_MAX);
>
> This adds an explicit typecast to avoid the warning
>
> Signed-off-by: Arnd Bergmann
> Fixes: 500899c2cc3e ("efi: ARM/arm64: ignore DT memory nodes instead of
> removing them")
Acked-by: Ard Biesheuvel
> ---
> drivers/firmware/efi/arm-init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index 434dd6065935..fac567c3b66a 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -149,7 +149,7 @@ static __init void reserve_regions(void)
> * uses its own memory map instead.
> */
> memblock_dump_all();
> - memblock_remove(0, ULLONG_MAX);
> + memblock_remove(0, (phys_addr_t)ULLONG_MAX);
>
> for_each_efi_memory_desc(&memmap, md) {
> paddr = md->phys_addr;
> --
> 2.7.0
>
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On 18 April 2016 at 16:31, Herbert Xu wrote: > On Mon, Apr 18, 2016 at 04:28:46PM +0800, Baolin Wang wrote: >> >> What I meaning is if the xts engine can support bulk block, then the >> engine driver can select bulk mode to do encryption, but if their xts >> engine can not support bulk mode, which depends on hardware design, >> the engine driver can not select bulk mode. So the dm-crypt can not >> know what will be selected by the engine driver, it can not send one >> bulk block each time. > > Why can't the xts code just break it up if it can't handle it? Simply to say, now there are many different hardware engines for different vendors, some engines can support bulk block but some can not (or no cipher hardware engine), then the dm-crypt can not know your hardware engine features. If the dm-crypt send one bulk block to low level, but the engine driver can not support bulk block, then it will crash. So we did the merging action in driver level not dm-crypt level. > > You want to postpone splitting as much as possible. Even if the > underlying xts code couldn't handle it, it would still make sense > for the crypto API to see the request in one piece. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Baolin.wang Best Regards
[PATCH] coresight: etm4x: Add DT implementation.
Add DT implementation for A72 and Atermis board.
Signed-off-by: Li Pengcheng
Signed-off-by: Li Zhong
---
drivers/hwtracing/coresight/coresight-etm4x.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
b/drivers/hwtracing/coresight/coresight-etm4x.c
index 6396b28..76bfad1 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -825,6 +825,16 @@ static struct amba_id etm4_ids[] = {
.mask = 0x000f,
.data = "ETM 4.0",
},
+ { /* ETM 4.0 - A72 board */
+ .id = 0x000bb95a,
+ .mask = 0x000f,
+ .data = "ETM 4.0",
+ },
+ { /* ETM 4.0 - Atermis board */
+ .id = 0x000bb959,
+ .mask = 0x000f,
+ .data = "ETM 4.0",
+ },
{ 0, 0},
};
--
1.8.3.2
Re: [PATCH 03/10] mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race
On 04/11/2016 11:34 AM, Anshuman Khandual wrote: > On 04/07/2016 03:04 PM, kbuild test robot wrote: >> > All errors (new ones prefixed by >>): >> > >> >mm/hugetlb.c: In function 'follow_huge_pud': >> >>> >> mm/hugetlb.c:4360:3: error: implicit declaration of function >> >>> >> 'pud_page' [-Werror=implicit-function-declaration] >> > page = pud_page(*pud) + ((address & ~PUD_MASK) >> PAGE_SHIFT); >> > ^ >> >mm/hugetlb.c:4360:8: warning: assignment makes pointer from integer >> > without a cast >> > page = pud_page(*pud) + ((address & ~PUD_MASK) >> PAGE_SHIFT); >> >^ >> >mm/hugetlb.c: In function 'follow_huge_pgd': >> >mm/hugetlb.c:4395:3: error: implicit declaration of function 'pgd_page' >> > [-Werror=implicit-function-declaration] >> > page = pgd_page(*pgd) + ((address & ~PGDIR_MASK) >> PAGE_SHIFT); > Both the build errors here are because of the fact that pgd_page() is > not available for some platforms and config options. It got missed as > I ran only powerpc config options for build test purpose. My bad, will > fix it. The following change seems to fix the build problem on S390 but will require some inputs from S390 maintainers regarding the functional correctness of the patch. diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h index 2f66645..834a8a6 100644 --- a/arch/s390/include/asm/pgtable.h +++ b/arch/s390/include/asm/pgtable.h @@ -963,6 +963,8 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address) #define pte_page(x) pfn_to_page(pte_pfn(x)) #define pmd_page(pmd) pfn_to_page(pmd_pfn(pmd)) +#define pud_page(pud) pud_val(pud) +#define pgd_page(pgd) pgd_val(pgd)
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On Mon, Apr 18, 2016 at 04:40:36PM +0800, Baolin Wang wrote: > > Simply to say, now there are many different hardware engines for > different vendors, some engines can support bulk block but some can > not (or no cipher hardware engine), then the dm-crypt can not know > your hardware engine features. If the dm-crypt send one bulk block to > low level, but the engine driver can not support bulk block, then it > will crash. So we did the merging action in driver level not dm-crypt > level. Surely we can handle it in the crypto API layer, just as we do GSO in the network stack for drivers that can't handle TSO? Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 03/10] mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race
On 04/07/2016 02:46 PM, kbuild test robot wrote: > Hi Anshuman, > > [auto build test ERROR on powerpc/next] > [also build test ERROR on v4.6-rc2 next-20160407] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: > https://github.com/0day-ci/linux/commits/Anshuman-Khandual/Enable-HugeTLB-page-migration-on-POWER/20160407-165841 > base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next > config: sparc64-allyesconfig (attached as .config) > 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=sparc64 > > All error/warnings (new ones prefixed by >>): > >mm/hugetlb.c: In function 'follow_huge_pgd': >>> >> mm/hugetlb.c:4395:3: error: implicit declaration of function 'pgd_page' >>> >> [-Werror=implicit-function-declaration] > page = pgd_page(*pgd) + ((address & ~PGDIR_MASK) >> PAGE_SHIFT); > ^ The following change seems to fix the build problem on SPARC but will require some inputs from SPARC maintainers regarding the functional correctness of the patch. diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h index f089cfa..7b7e6a0 100644 --- a/arch/sparc/include/asm/pgtable_64.h +++ b/arch/sparc/include/asm/pgtable_64.h @@ -804,6 +804,7 @@ static inline unsigned long __pmd_page(pmd_t pmd) #define pmd_clear(pmdp)(pmd_val(*(pmdp)) = 0UL) #define pud_present(pud) (pud_val(pud) != 0U) #define pud_clear(pudp)(pud_val(*(pudp)) = 0UL) +#define pgd_page(pgd) (pgd_val(pgd)) #define pgd_page_vaddr(pgd)\ ((unsigned long) __va(pgd_val(pgd))) #define pgd_present(pgd) (pgd_val(pgd) != 0U)
Re: [PATCH v3 1/6] rtmutex: Deboost before waking up the top waiter
On 2016/04/18 at 16:23, Thomas Gleixner wrote: > On Thu, 14 Apr 2016, Xunlei Pang wrote: >> We should deboost before waking the high-prio task such that >> we don't run two tasks with the 'same' priority. > No. This is fundamentaly broken. > > T1 (prio 0) lock(X) > > --> preemption > > T2 (prio 10) lock(X) > boost(T1) > schedule() > > T1 (prio 10) unlock(X) We add a preempt_disable() before deboost to avoid the breakage, there's also some comment about this in the patch's code. Regards, Xunlei > deboost() >(prio 0) > > --> preemption > > T3 (prio 5) > > Classic priority inversion enabled by a mechanism to avoid it. Brilliant > stuff. > > Thanks, > > tglx
[patch -next] udp: fix if statement in SIOCINQ ioctl
We deleted a line of code and accidentally made the "return put_user()"
part of the if statement when it's supposed to be unconditional.
Fixes: 9f9a45beaa96 ('udp: do not expect udp headers on ioctl SIOCINQ')
Signed-off-by: Dan Carpenter
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index f186313..37e09c3 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1276,12 +1276,6 @@ int udp_ioctl(struct sock *sk, int cmd, unsigned long
arg)
{
unsigned int amount = first_packet_length(sk);
- if (amount)
- /*
-* We will only return the amount
-* of this packet since that is all
-* that will be read.
-*/
return put_user(amount, (int __user *)arg);
}
Re: [PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address
On Sat, Apr 16, 2016 at 02:58:58AM +0900, Masahiro Yamada wrote:
> As Documentation/arm64/booting.txt says, the cpu-release-addr
> location should be reserved.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
> b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
> index 651c9d9..90909d2 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
> @@ -42,6 +42,8 @@
> * OTHER DEALINGS IN THE SOFTWARE.
> */
>
> +/memreserve/ 0x8100 0x0008;
> +
Please add a comment above the memreserve to mention what it is
protecting. That helps to avoid having this cargo-culted to cases where
it is not needed.
I take it that the code for the spin-table is not in RAM, and does not
need to be protected similarly?
Assuming so:
Acked-by: Mark Rutland
Thanks,
Mark.
> / {
> compatible = "socionext,ph1-ld20";
> #address-cells = <2>;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH 2/2] Staging: Lustre: Fixed coding style issues
On Sun, 2016-04-17 at 21:35 +, Drokin, Oleg wrote: > On Apr 17, 2016, at 10:11 AM, Panos Vlachos wrote: > > Fixed one coding style issue in the > > file router_proc.c (Lustre staging driver) > Perhaps it's best to reference what the issue is. > I.e. "Fix too long line in …" > and then in the actual message add that you just split it? [] > > diff --git a/drivers/staging/lustre/lnet/lnet/router_proc.c > > b/drivers/staging/lustre/lnet/lnet/router_proc.c [] > > @@ -32,7 +32,8 @@ > > */ > > #define LNET_PROC_CPT_BITS (LNET_CPT_BITS + 1) > > /* change version, 16 bits or 8 bits */ > > -#define LNET_PROC_VER_BITS max_t(size_t, min_t(size_t, LNET_LOFFT_BITS, > > 64) / 4, 8) > > +#define LNET_PROC_VER_BITS \ > > +max_t(size_t, min_t(size_t, LNET_LOFFT_BITS, 64) / 4, 8) > Hm, I am not sure this is an improvement, you might want to at least place a > tab at the start of this > second line, so that indentation helps us better see it's a continuation of > the previous one. Given: #define LNET_LOFFT_BITS (sizeof(loff_t) * 8) and: include/linux/types.h:typedef __kernel_loff_t loff_t; include/uapi/asm-generic/posix_types.h:typedef long long __kernel_loff_t; and this isn't going to change any time soon, maybe this #define isn't particularly useful and #define LNET_PROC_VER_BITS 16 is sufficient.
Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework
On 18 April 2016 at 16:41, Herbert Xu wrote: > On Mon, Apr 18, 2016 at 04:40:36PM +0800, Baolin Wang wrote: >> >> Simply to say, now there are many different hardware engines for >> different vendors, some engines can support bulk block but some can >> not (or no cipher hardware engine), then the dm-crypt can not know >> your hardware engine features. If the dm-crypt send one bulk block to >> low level, but the engine driver can not support bulk block, then it >> will crash. So we did the merging action in driver level not dm-crypt >> level. > > Surely we can handle it in the crypto API layer, just as we do GSO > in the network stack for drivers that can't handle TSO? Yes, it is similar. Thanks. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Baolin.wang Best Regards
Re: [PATCH v2 1/3] PCI: imx6: Use enum instead of bool for variant indicator
Am Sonntag, den 17.04.2016, 22:51 -0700 schrieb Andrey Smirnov:
> Use enumerated type instead of a boolean flag to specify the variant of
> the PCIe IP block (6Q, 6SX, etc). This patch has zero functional impact,
> however it makes the code easier to extend for the case of more than 2
> possible variants of an IP block (of which there are).
>
This is the right thing to do, but I'm not yet satisfied with the
implementation.
> Signed-off-by: Andrey Smirnov
> ---
>
> Changes since v1:
>
> - Patchset is rebased against
>
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-imx6
>
> - DTS files changes moved into a separate patch
>
>
> drivers/pci/host/pci-imx6.c | 126
> +---
> 1 file changed, 71 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index 0f6d630..c570bbb 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -31,6 +31,11 @@
>
> #define to_imx6_pcie(x) container_of(x, struct imx6_pcie, pp)
>
> +enum imx6_pcie_variants {
> + IMX6Q,
> + IMX6SX
> +};
> +
> struct imx6_pcie {
> struct gpio_desc*reset_gpio;
> struct clk *pcie_bus;
> @@ -39,7 +44,7 @@ struct imx6_pcie {
> struct clk *pcie;
> struct pcie_portpp;
> struct regmap *iomuxc_gpr;
> - boolis_imx6sx;
> + enum imx6_pcie_variants variant;
> void __iomem*mem_base;
> u32 tx_deemph_gen1;
> u32 tx_deemph_gen2_3p5db;
> @@ -238,7 +243,8 @@ static int imx6_pcie_assert_core_reset(struct pcie_port
> *pp)
> struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> u32 val, gpr1, gpr12;
>
> - if (imx6_pcie->is_imx6sx) {
> + switch (imx6_pcie->variant) {
> + case IMX6SX:
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
> IMX6SX_GPR12_PCIE_TEST_POWERDOWN);
> @@ -246,72 +252,80 @@ static int imx6_pcie_assert_core_reset(struct pcie_port
> *pp)
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5,
> IMX6SX_GPR5_PCIE_BTNRST_RESET,
> IMX6SX_GPR5_PCIE_BTNRST_RESET);
> - return 0;
> - }
> -
> - /*
> - * If the bootloader already enabled the link we need some special
> - * handling to get the core back into a state where it is safe to
> - * touch it for configuration. As there is no dedicated reset signal
> - * wired up for MX6QDL, we need to manually force LTSSM into "detect"
> - * state before completely disabling LTSSM, which is a prerequisite
> - * for core configuration.
> - *
> - * If both LTSSM_ENABLE and REF_SSP_ENABLE are active we have a strong
> - * indication that the bootloader activated the link.
> - */
> - regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, &gpr1);
> - regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, &gpr12);
> -
> - if ((gpr1 & IMX6Q_GPR1_PCIE_REF_CLK_EN) &&
> - (gpr12 & IMX6Q_GPR12_PCIE_CTL_2)) {
> - val = readl(pp->dbi_base + PCIE_PL_PFLR);
> - val &= ~PCIE_PL_PFLR_LINK_STATE_MASK;
> - val |= PCIE_PL_PFLR_FORCE_LINK;
> - writel(val, pp->dbi_base + PCIE_PL_PFLR);
> + break;
> + case IMX6Q:
> + /*
> + * If the bootloader already enabled the link we need some
> special
> + * handling to get the core back into a state where it is safe
> to
> + * touch it for configuration. As there is no dedicated reset
> signal
> + * wired up for MX6QDL, we need to manually force LTSSM into
> "detect"
> + * state before completely disabling LTSSM, which is a
> prerequisite
> + * for core configuration.
> + *
> + * If both LTSSM_ENABLE and REF_SSP_ENABLE are active we have a
> strong
> + * indication that the bootloader activated the link.
> + */
> + regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, &gpr1);
> + regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, &gpr12);
> +
> + if ((gpr1 & IMX6Q_GPR1_PCIE_REF_CLK_EN) &&
> + (gpr12 & IMX6Q_GPR12_PCIE_CTL_2)) {
> + val = readl(pp->dbi_base + PCIE_PL_PFLR);
> + val &= ~PCIE_PL_PFLR_LINK_STATE_MASK;
> + val |= PCIE_PL_PFLR_FORCE_LINK;
> + writel(val, pp->dbi_base + PCIE_PL_PFLR);
> +
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> +IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
> + }
>
> - regmap_upda
Re: [PATCH 00/10] Enable HugeTLB page migration on POWER
On 04/07/2016 11:07 AM, Anshuman Khandual wrote: > This patch series enables HugeTLB page migration on POWER platform. > This series has some core VM changes (patch 1, 2, 3) and some powerpc > specific changes (patch 4, 5, 6, 7, 8, 9, 10). Comments, suggestions > and inputs are welcome. > > Anshuman Khandual (10): > mm/mmap: Replace SHM_HUGE_MASK with MAP_HUGE_MASK inside mmap_pgoff > mm/hugetlb: Add PGD based implementation awareness > mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race Hugh/Mel/Naoya/Andrew, Andrew had already reviewed the changes in the first two patches during the RFC phase and was okay with them. Could you please review the third patch here as well and let me know your inputs/suggestions. Currently the third patch has got build failures on SPARC and S390 platforms (details of which are on the thread with possible fixes). Thank you.
Re: [PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address
Hi Mark, 2016-04-18 17:45 GMT+09:00 Mark Rutland : > On Sat, Apr 16, 2016 at 02:58:58AM +0900, Masahiro Yamada wrote: >> As Documentation/arm64/booting.txt says, the cpu-release-addr >> location should be reserved. >> >> Signed-off-by: Masahiro Yamada >> --- >> >> arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi >> b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi >> index 651c9d9..90909d2 100644 >> --- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi >> +++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi >> @@ -42,6 +42,8 @@ >> * OTHER DEALINGS IN THE SOFTWARE. >> */ >> >> +/memreserve/ 0x8100 0x0008; >> + > > Please add a comment above the memreserve to mention what it is > protecting. That helps to avoid having this cargo-culted to cases where > it is not needed. OK, will do. > I take it that the code for the spin-table is not in RAM, and does not > need to be protected similarly? I use U-Boot to boot Linux for this board. The code for the spin-table is on SDRAM, and not protected. I already recognize this problem. The difficulty for U-Boot is that U-Boot relocates itself to the top of the DRAM. So, it is difficult to predict where the code will be placed. I will discuss this issue in the U-Boot ML. So, My current solution is pre-fetch the code for the spin-table onto I-cache. -- Best Regards Masahiro Yamada
Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework
Hi Jun,
On 18 April 2016 at 16:27, Jun Li wrote:
>> >>
>> >> But another issue is some users may need to get the charger type from
>> >> power supply by "power_supply_get_property()" function, we need to
>> >> integrate with the power supply things in the usb charger framework,
>> >> not user to implement that.
>> >
>> > Why this user(your case) can't put the charger type get by
>> > "power_supply_get_property()" in its uchger->charger_detect(), any
>> > special reason prevent you doing it? I am not sure if this case is
>> > very common, even if it is, you also can put it in
>> > usb_charger_detect_type()
>> >
>> > usb_charger_detect_type()
>> > {
>> > If can get from power_supply_get_property()
>> > ...
>> > else if uchger->charger_detect
>> > uchger->charger_detect();
>> > ...
>> > }
>>
>> If user want to implement above method, they need to get the
>> 'power_supply' structure to do this action, which maybe can not get in
>> some contexts. So we need to integrate with the power supply things to
>> avoid this situation. IIRC, Felipe suggested me to flesh out the charger
>> getting method.
>>
>
> Okay, then I agree with you to let user do that with more flexibility,
> I tried to enable usb charger detection on one NXP i.mx platform based on
> this framework, works fine, thanks!
That's great. Thanks.
--
Baolin.wang
Best Regards
[PATCH 1/3] gpio: tegra: Don't open code of_device_get_match_data()
Use of_device_get_match_data() for getting matched data
instead of implementing this locally.
Signed-off-by: Laxman Dewangan
---
drivers/gpio/gpio-tegra.c | 50 +++
1 file changed, 24 insertions(+), 26 deletions(-)
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 790bb11..1b0c497 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -75,6 +75,11 @@ struct tegra_gpio_bank {
#endif
};
+struct tegra_gpio_soc_config {
+ u32 bank_stride;
+ u32 upper_offset;
+};
+
static struct device *dev;
static struct irq_domain *irq_domain;
static void __iomem *regs;
@@ -445,27 +450,6 @@ static const struct dev_pm_ops tegra_gpio_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(tegra_gpio_suspend, tegra_gpio_resume)
};
-struct tegra_gpio_soc_config {
- u32 bank_stride;
- u32 upper_offset;
-};
-
-static struct tegra_gpio_soc_config tegra20_gpio_config = {
- .bank_stride = 0x80,
- .upper_offset = 0x800,
-};
-
-static struct tegra_gpio_soc_config tegra30_gpio_config = {
- .bank_stride = 0x100,
- .upper_offset = 0x80,
-};
-
-static const struct of_device_id tegra_gpio_of_match[] = {
- { .compatible = "nvidia,tegra30-gpio", .data = &tegra30_gpio_config },
- { .compatible = "nvidia,tegra20-gpio", .data = &tegra20_gpio_config },
- { },
-};
-
/* This lock class tells lockdep that GPIO irqs are in a different
* category than their parents, so it won't report false recursion.
*/
@@ -473,8 +457,7 @@ static struct lock_class_key gpio_lock_class;
static int tegra_gpio_probe(struct platform_device *pdev)
{
- const struct of_device_id *match;
- struct tegra_gpio_soc_config *config;
+ const struct tegra_gpio_soc_config *config;
struct resource *res;
struct tegra_gpio_bank *bank;
int ret;
@@ -484,12 +467,11 @@ static int tegra_gpio_probe(struct platform_device *pdev)
dev = &pdev->dev;
- match = of_match_device(tegra_gpio_of_match, &pdev->dev);
- if (!match) {
+ config = of_device_get_match_data(&pdev->dev);
+ if (!config) {
dev_err(&pdev->dev, "Error: No device match found\n");
return -ENODEV;
}
- config = (struct tegra_gpio_soc_config *)match->data;
tegra_gpio_bank_stride = config->bank_stride;
tegra_gpio_upper_offset = config->upper_offset;
@@ -578,6 +560,22 @@ static int tegra_gpio_probe(struct platform_device *pdev)
return 0;
}
+static struct tegra_gpio_soc_config tegra20_gpio_config = {
+ .bank_stride = 0x80,
+ .upper_offset = 0x800,
+};
+
+static struct tegra_gpio_soc_config tegra30_gpio_config = {
+ .bank_stride = 0x100,
+ .upper_offset = 0x80,
+};
+
+static const struct of_device_id tegra_gpio_of_match[] = {
+ { .compatible = "nvidia,tegra30-gpio", .data = &tegra30_gpio_config },
+ { .compatible = "nvidia,tegra20-gpio", .data = &tegra20_gpio_config },
+ { },
+};
+
static struct platform_driver tegra_gpio_driver = {
.driver = {
.name = "tegra-gpio",
--
2.1.4
[PATCH 3/3] gpio: tegra: Add support for gpio debounce
NVIDIA's Tegra210 support the HW debounce in the GPIO
controller for all its GPIO pins.
Add support for setting debounce timing by implementing the
set_debounce callback of gpiochip.
Signed-off-by: Laxman Dewangan
---
drivers/gpio/gpio-tegra.c | 48 +++
1 file changed, 48 insertions(+)
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index de022a9..9f7d75b 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -46,6 +46,7 @@
#define GPIO_INT_ENB(x)(GPIO_REG(x) + 0x50)
#define GPIO_INT_LVL(x)(GPIO_REG(x) + 0x60)
#define GPIO_INT_CLR(x)(GPIO_REG(x) + 0x70)
+#define GPIO_DBC_CNT(x)(GPIO_REG(x) + 0xF0)
#define GPIO_MSK_CNF(x)(GPIO_REG(x) + tegra_gpio_upper_offset
+ 0x00)
#define GPIO_MSK_OE(x) (GPIO_REG(x) + tegra_gpio_upper_offset + 0x10)
@@ -53,6 +54,7 @@
#define GPIO_MSK_INT_STA(x)(GPIO_REG(x) + tegra_gpio_upper_offset + 0x40)
#define GPIO_MSK_INT_ENB(x)(GPIO_REG(x) + tegra_gpio_upper_offset + 0x50)
#define GPIO_MSK_INT_LVL(x)(GPIO_REG(x) + tegra_gpio_upper_offset + 0x60)
+#define GPIO_MSK_DBC_EN(x) (GPIO_REG(x) + tegra_gpio_upper_offset + 0x30)
#define GPIO_INT_LVL_MASK 0x010101
#define GPIO_INT_LVL_EDGE_RISING 0x000101
@@ -72,12 +74,15 @@ struct tegra_gpio_bank {
u32 int_enb[4];
u32 int_lvl[4];
u32 wake_enb[4];
+ u32 dbc_enb[4];
+ u32 dbc_cnt[4];
#endif
};
struct tegra_gpio_soc_config {
u32 bank_stride;
u32 upper_offset;
+ bool debounce_supported;
};
static struct irq_domain *irq_domain;
@@ -164,6 +169,31 @@ static int tegra_gpio_direction_output(struct gpio_chip
*chip, unsigned offset,
return 0;
}
+static int tegra_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
+ unsigned int debounce)
+{
+ unsigned int max_dbc;
+ unsigned int debounce_ms = DIV_ROUND_UP(debounce, 1000);
+
+ if (!debounce_ms) {
+ tegra_gpio_mask_write(GPIO_MSK_DBC_EN(offset), offset, 0);
+ return 0;
+ }
+
+ debounce_ms = min(debounce_ms, 255U);
+
+ /* There is only one debounce count register per port and hence
+* set the maximum of current and requested debounce time.
+*/
+ max_dbc = tegra_gpio_readl(GPIO_DBC_CNT(offset));
+ max_dbc = max(max_dbc, debounce_ms);
+
+ tegra_gpio_mask_write(GPIO_MSK_DBC_EN(offset), offset, 1);
+ tegra_gpio_writel(max_dbc, GPIO_DBC_CNT(offset));
+
+ return 0;
+}
+
static int tegra_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
{
return irq_find_mapping(irq_domain, offset);
@@ -177,6 +207,7 @@ static struct gpio_chip tegra_gpio_chip = {
.get= tegra_gpio_get,
.direction_output = tegra_gpio_direction_output,
.set= tegra_gpio_set,
+ .set_debounce = tegra_gpio_set_debounce,
.to_irq = tegra_gpio_to_irq,
.base = 0,
};
@@ -327,6 +358,9 @@ static int tegra_gpio_resume(struct device *dev)
tegra_gpio_writel(bank->oe[p], GPIO_OE(gpio));
tegra_gpio_writel(bank->int_lvl[p], GPIO_INT_LVL(gpio));
tegra_gpio_writel(bank->int_enb[p], GPIO_INT_ENB(gpio));
+ tegra_gpio_writel(bank->dbc_enb[p],
+ GPIO_MSK_DBC_EN(gpio));
+ tegra_gpio_writel(bank->dbc_cnt[p], GPIO_DBC_CNT(gpio));
}
}
@@ -351,6 +385,11 @@ static int tegra_gpio_suspend(struct device *dev)
bank->oe[p] = tegra_gpio_readl(GPIO_OE(gpio));
bank->int_enb[p] = tegra_gpio_readl(GPIO_INT_ENB(gpio));
bank->int_lvl[p] = tegra_gpio_readl(GPIO_INT_LVL(gpio));
+ bank->dbc_enb[p] = tegra_gpio_readl(
+ GPIO_MSK_DBC_EN(gpio));
+ bank->dbc_enb[p] = (bank->dbc_enb[p] << 8) ||
+ bank->dbc_enb[p];
+ bank->dbc_cnt[p] = tegra_gpio_readl(GPIO_DBC_CNT(gpio));
/* Enable gpio irq for wake up source */
tegra_gpio_writel(bank->wake_enb[p],
@@ -473,6 +512,8 @@ static int tegra_gpio_probe(struct platform_device *pdev)
tegra_gpio_bank_stride = config->bank_stride;
tegra_gpio_upper_offset = config->upper_offset;
+ if (!config->debounce_supported)
+ tegra_gpio_chip.set_debounce = NULL;
for (;;) {
res = platform_get_resource(pdev, IORESOURCE_IRQ,
tegra_gpio_bank_count);
@@ -570,7 +611,14 @@ static struct tegra_gpio_soc_config tegra30_gpio_config = {
.upper_offset =
[PATCH 2/3] gpio: tegra: Remove the need of keeping device handle for gpio driver
Remove the file static device handle variable as this is just
required for prints. The required handle can be stored in
tegra_gpio_chip and hence it become redundancy.
Signed-off-by: Laxman Dewangan
---
drivers/gpio/gpio-tegra.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 1b0c497..de022a9 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -80,7 +80,6 @@ struct tegra_gpio_soc_config {
u32 upper_offset;
};
-static struct device *dev;
static struct irq_domain *irq_domain;
static void __iomem *regs;
static u32 tegra_gpio_bank_count;
@@ -240,7 +239,8 @@ static int tegra_gpio_irq_set_type(struct irq_data *d,
unsigned int type)
ret = gpiochip_lock_as_irq(&tegra_gpio_chip, gpio);
if (ret) {
- dev_err(dev, "unable to lock Tegra GPIO %d as IRQ\n", gpio);
+ dev_err(tegra_gpio_chip.parent,
+ "unable to lock Tegra GPIO %d as IRQ\n", gpio);
return ret;
}
@@ -465,8 +465,6 @@ static int tegra_gpio_probe(struct platform_device *pdev)
int i;
int j;
- dev = &pdev->dev;
-
config = of_device_get_match_data(&pdev->dev);
if (!config) {
dev_err(&pdev->dev, "Error: No device match found\n");
@@ -488,6 +486,8 @@ static int tegra_gpio_probe(struct platform_device *pdev)
}
tegra_gpio_chip.ngpio = tegra_gpio_bank_count * 32;
+ tegra_gpio_chip.parent = &pdev->dev;
+
tegra_gpio_banks = devm_kzalloc(&pdev->dev,
tegra_gpio_bank_count * sizeof(*tegra_gpio_banks),
--
2.1.4
Re: [PATCH v2 2/3] PCI: imx6: Implement reset sequence for i.MX6+
Am Sonntag, den 17.04.2016, 22:51 -0700 schrieb Andrey Smirnov:
> I.MX6+ has a dedicated bit for reseting PCIe core, which should be used
> instead of a regular reset sequence since using the latter will hang the
> SoC.
>
> This commit is based on c34068d48273e24d392d9a49a38be807954420ed from
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git
>
> Signed-off-by: Andrey Smirnov
> ---
>
> Changes since v1:
>
> - Patchset is rebased against
>
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-imx6
>
> - DTS files changes moved into a separate patch
>
> drivers/pci/host/pci-imx6.c | 28 ++--
> include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 1 +
> 2 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index c570bbb..834c5b8 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -33,7 +33,8 @@
>
> enum imx6_pcie_variants {
> IMX6Q,
> - IMX6SX
> + IMX6SX,
> + IMX6QP,
> };
>
> struct imx6_pcie {
> @@ -253,6 +254,11 @@ static int imx6_pcie_assert_core_reset(struct pcie_port
> *pp)
> IMX6SX_GPR5_PCIE_BTNRST_RESET,
> IMX6SX_GPR5_PCIE_BTNRST_RESET);
> break;
> + case IMX6QP:
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> +IMX6Q_GPR1_PCIE_SW_RST,
> +IMX6Q_GPR1_PCIE_SW_RST);
> + break;
> case IMX6Q:
> /*
>* If the bootloader already enabled the link we need some
> special
> @@ -307,6 +313,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie
> *imx6_pcie)
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
> break;
> + case IMX6QP:/* FALLTHROUGH */
> case IMX6Q:
> /* power up core phy and enable ref clock */
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> @@ -367,9 +374,22 @@ static int imx6_pcie_deassert_core_reset(struct
> pcie_port *pp)
> gpiod_set_value_cansleep(imx6_pcie->reset_gpio, 1);
> }
>
> - if (imx6_pcie->variant == IMX6SX)
> + switch (imx6_pcie->variant) {
> + case IMX6SX:
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5,
> IMX6SX_GPR5_PCIE_BTNRST_RESET, 0);
> + break;
> + case IMX6QP:
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> +IMX6Q_GPR1_PCIE_SW_RST, 0);
> +
> + usleep_range(200, 500);
> + break;
> + case IMX6Q: /* Nothing to do */
> + break;
> + default:
> + BUG();
> + }
>
> return 0;
>
> @@ -601,6 +621,9 @@ static int __init imx6_pcie_probe(struct platform_device
> *pdev)
> if (of_device_is_compatible(pp->dev->of_node,
> "fsl,imx6sx-pcie"))
> imx6_pcie->variant = IMX6SX;
> + else if (of_device_is_compatible(pp->dev->of_node,
> + "fsl,imx6qp-pcie"))
> + imx6_pcie->variant = IMX6QP;
> else
> imx6_pcie->variant = IMX6Q;
>
> @@ -697,6 +720,7 @@ static void imx6_pcie_shutdown(struct platform_device
> *pdev)
> static const struct of_device_id imx6_pcie_of_match[] = {
> { .compatible = "fsl,imx6q-pcie", },
> { .compatible = "fsl,imx6sx-pcie", },
> + { .compatible = "fsl,imx6qp-pcie", },
New DT compatibles must be documented in
Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt.
Otherwise same comments as on the first patch.
> {},
> };
> MODULE_DEVICE_TABLE(of, imx6_pcie_of_match);
> diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
> b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
> index 238c8db..5b08e3c 100644
> --- a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
> +++ b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
> @@ -95,6 +95,7 @@
> #define IMX6Q_GPR0_DMAREQ_MUX_SEL0_IOMUX BIT(0)
>
> #define IMX6Q_GPR1_PCIE_REQ_MASK (0x3 << 30)
> +#define IMX6Q_GPR1_PCIE_SW_RST BIT(29)
> #define IMX6Q_GPR1_PCIE_EXIT_L1 BIT(28)
> #define IMX6Q_GPR1_PCIE_RDY_L23 BIT(27)
> #define IMX6Q_GPR1_PCIE_ENTER_L1 BIT(26)
Re: [PATCH v2 3/3] ARM: dts: imx6qp: Specify imx6qp version of PCIe core
Am Sonntag, den 17.04.2016, 22:51 -0700 schrieb Andrey Smirnov:
> I.MX6Quad Plus has a slightly different version of PCIe core than
> reqular i.MX6Quad.
>
> Signed-off-by: Andrey Smirnov
Under the assumption that the missing documentation for this compatible
is added in patch 2/3 in the next revision of this patchset:
Reviewed-by: Lucas Stach
> ---
>
> Changes since v1:
>
> - Patchset is rebased against
>
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-imx6
>
> - DTS files changes moved into a separate patch
>
> arch/arm/boot/dts/imx6qp.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qp.dtsi b/arch/arm/boot/dts/imx6qp.dtsi
> index 1ada714..886dbf2 100644
> --- a/arch/arm/boot/dts/imx6qp.dtsi
> +++ b/arch/arm/boot/dts/imx6qp.dtsi
> @@ -82,5 +82,8 @@
> "ldb_di0", "ldb_di1", "prg";
> };
>
> + pcie: pcie@0x0100 {
> + compatible = "fsl,imx6qp-pcie", "snps,dw-pcie";
> + };
> };
> };
Re: [PATCH v3 1/6] rtmutex: Deboost before waking up the top waiter
On Mon, 18 Apr 2016, Xunlei Pang wrote: > On 2016/04/18 at 16:23, Thomas Gleixner wrote: > > On Thu, 14 Apr 2016, Xunlei Pang wrote: > >> We should deboost before waking the high-prio task such that > >> we don't run two tasks with the 'same' priority. > > No. This is fundamentaly broken. > > > > T1 (prio 0) lock(X) > > > > --> preemption > > > > T2 (prio 10)lock(X) > > boost(T1) > > schedule() > > > > T1 (prio 10)unlock(X) > > We add a preempt_disable() before deboost to avoid the breakage, > there's also some comment about this in the patch's code. So the changelog is useless and misleading. Neither does it explain what's wrong with having two tasks with the same priority in running state. Thanks, tglx
Re: [PATCH] arm64: dts: uniphier: add /memreserve/ for spin-table release address
On Mon, Apr 18, 2016 at 05:55:14PM +0900, Masahiro Yamada wrote: > 2016-04-18 17:45 GMT+09:00 Mark Rutland : > > I take it that the code for the spin-table is not in RAM, and does not > > need to be protected similarly? > > I use U-Boot to boot Linux for this board. > > The code for the spin-table is on SDRAM, and not protected. > > I already recognize this problem. > > The difficulty for U-Boot is that > U-Boot relocates itself to the top of the DRAM. > So, it is difficult to predict > where the code will be placed. > > I will discuss this issue in the U-Boot ML. Ok, please do. > So, My current solution is pre-fetch the code for the spin-table onto > I-cache. As you are probably aware, this is incredibly unsafe, and very likely to go wrong. Nothing guarantees that (stale) entries remain in the I-cache. I would very much advise fixing this ASAP. Thanks, Mark.
Re: [PATCH v3] ARM64: ACPI: Update documentation for latest specification version
On Fri, Apr 15, 2016 at 11:54:08AM -0600, Al Stone wrote:
[...]
> > Understood, the point I wanted to make is that adding a list of methods
> > in acpi_object_usage.txt ("Use as needed") is not necessarily additional
> > information, you can add a pointer at ACPI specs (for that specific
> > purpose - as I said there are parts of the patch that add additional
> > information Linux related) for that purpose instead of having to list
> > all of them in acpi_object_usage.txt again.
>
> I see. That makes sense. How about I collapse those down with something
> on the order of "unless otherwise noted, use as needed" and just remove the
> ones that have no specific info?
Agreed, that would also help you avoid keeping track of new specs
updates that do not necessarily require updates to these docs.
Lorenzo
Re: [PATCH v5] ARC: clockevent: DT based probe
On Mon, Apr 18, 2016 at 12:16:10PM +0530, Vineet Gupta wrote:
> - timer frequency is derived from DT (no longer rely on top level
>DT "clock-frequency" probed early and exported by asm/clk.h)
>
> - TIMER0_IRQ need not be exported across arch code, confined to intc as
>it is property of same
>
> - Any failures in clockevent setup are considered pedantic and system
>panic()'s as there is no generic fallback (unlike clocksource where
>a jiffies based soft clocksource always exists)
>
> Cc: Daniel Lezcano
> Signed-off-by: Vineet Gupta
> ---
> Changes since v4 [*]
> - clockevent setup failure panic()s bubbled up to top level function [Daniel]
> - arc_get_timer_clk() returns error status vs. void [Daniel]
> - For consistency, straggler pr_err() in setup function also converted to
> panic
>
> [*] http://lists.infradead.org/pipermail/linux-snps-arc/2016-April/000903.html
[ ... ]
> +static int noinline arc_get_timer_clk(struct device_node *node)
> +{
> + struct clk *clk;
> + int ret = -1;
> +
> + clk = of_clk_get(node, 0);
> + if (IS_ERR(clk)) {
> + pr_err("timer missing clk");
> + return ret;
> + }
return PTR_ERR(clk);
> + ret = clk_prepare_enable(clk);
> + if (ret) {
> + pr_err("Couldn't enable parent clk\n");
> + return ret;
> + }
> +
> + arc_timer_freq = clk_get_rate(clk);
> + return ret;
> +}
With the change above: Acked-by: Daniel Lezcano
Re: linux-next: build warning after merge of the ipvs-next tree
On Fri, Apr 15, 2016 at 10:38:14PM +1000, Simon Horman wrote:
> On Fri, Apr 15, 2016 at 11:56:07AM +0200, Pablo Neira Ayuso wrote:
> > On Fri, Apr 15, 2016 at 10:57:48AM +1000, Stephen Rothwell wrote:
> > > Hi Simon,
> > >
> > > After merging the ipvs-next tree, today's linux-next build (powerpc
> > > ppc64_defconfig) produced this warning:
> > >
> > > net/netfilter/nf_conntrack_netlink.c:529:15: warning:
> > > 'ctnetlink_proto_size' defined but not used [-Wunused-function]
> > > static size_t ctnetlink_proto_size(const struct nf_conn *ct)
> > >^
> > > net/netfilter/nf_conntrack_netlink.c:546:15: warning:
> > > 'ctnetlink_acct_size' defined but not used [-Wunused-function]
> > > static size_t ctnetlink_acct_size(const struct nf_conn *ct)
> > >^
> > > net/netfilter/nf_conntrack_netlink.c:556:12: warning:
> > > 'ctnetlink_secctx_size' defined but not used [-Wunused-function]
> > > static int ctnetlink_secctx_size(const struct nf_conn *ct)
> > > ^
> > > net/netfilter/nf_conntrack_netlink.c:572:15: warning:
> > > 'ctnetlink_timestamp_size' defined but not used [-Wunused-function]
> > > static size_t ctnetlink_timestamp_size(const struct nf_conn *ct)
> > >^
> > > Introduced by commit
> > >
> > > 4054ff45454a ("netfilter: ctnetlink: remove unnecessary inlining")
> > >
> > > This build does not set CONFIG_NF_CONNTRACK_EVENTS or
> > > CONFIG_NETFILTER_NETLINK_GLUE_CT.
> >
> > This is my fault, will fix this asap. Thanks for reporting.
>
> Pablo,
>
> can you let me know when it is fixed in nf-next so I can rebase ipvs-next
> accordingly?
No need to rebase, will push an incremental fix for this.
Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
Hi Pavel,
On 04/15/2016 01:53 PM, Pavel Machek wrote:
Hi!
How about implementing patterns as a specific typer of triggers?
Let's say we have ledtrig-rgb-pattern:
Well, we'd need ledtrig-rgb-pattern-1, ledtrig-rgb-pattern-2, ... , as we
can have more than one rgb led. But yes.
Triggers can have many listeners, i.e. led_trigger_event() sets
brightness on all LED class devices registered on given trigger.
We could have led_trigger_rgb_event() that would set brightness
on all groups-of-three LEDs registered on given rgb-trigger.
I do not understand that.
Triggers are defined as kernel source of led events.
Currently we have two types of triggers as far as the source of
led event is concerned:
- triggers that are created per LED class device and therefore each
LED class device has their own source of kernel event,
initialized on trigger activation (e.g. ledtrig-timer,
ledtrig-heartbeat, ledtrig-oneshot),
- triggers that propagate kernel events from one source to many
listeners (e.g.ledtrig-ide-disk, ledtrig-cpu) - they internally
use led_trigger_event(), which iterates through all LED class devices
registered on a trigger and applies the same brightness.
In case of RGB trigger we'd like to have a common source of kernel
events for three LED class devices. After deeper analysis I'd modify
the approach a bit, in order to add a capability of generating kernel
led events from user space.
Let's say that we have LED RGB driver that exposes three LED class
devices: lp5523:red, lp5523:green, lp5523 blue.
$echo "rgb-pattern-lp5523" > /sys/class/leds/lp5523::red/trigger
$echo "red" > /sys/class/leds/lp5523::red/rgb_color
$echo "rgb-pattern-lp5523" > /sys/class/leds/lp5523::green/trigger
$echo "green" > /sys/class/leds/lp5523::green/rgb_color
$echo "rgb-pattern-lp5523" > /sys/class/leds/lp5523::blue/trigger
$echo "blue" > /sys/class/leds/lp5523::blue/rgb_color
led-rgb-pattern trigger would create a new trigger each time a non
existing rgp-pattern-* suffix is passed. In order to make it possible
for the user space to generate trigger events, a dedicated sysfs
interface would have to be exposed. How about creating a new LED RGB
class device that would expose "color" sysfs attribute with three space
separated R G B values? The device would appear in the sysfs after
rgb-pattern trigger is created.
Internally the LED RGB class device would use a new
led_trigger_rgb_event() to set the color:
void led_trigger_rgb_event(struct led_trigger *trig,
enum led_brightness red,
enum led_brightness green,
enum led_brightness blue,
{
struct led_classdev *led_cdev;
if (!trig)
return;
read_lock(&trig->leddev_list_lock);
list_for_each_entry(led_cdev, &trig->led_cdevs, trig_list)
if (led_cdev>flags & LED_RGB_COLOR_R)
led_set_brightness(led_cdev, red);
else if (led_cdev>flags & LED_RGB_COLOR_G)
led_set_brightness(led_cdev, green);
else if (led_cdev>flags & LED_RGB_COLOR_B)
led_set_brightness(led_cdev, blue);
read_unlock(&trig->leddev_list_lock);
}
I agree that ledtrig-rgb-pattern-1, ledtrig-rgb-pattern-2, etc. would
be also needed to add a capability of setting different colors on
different LED devices.
Ok.
For patterns, I'd suggest array of (r g b time) values.
Pattern engines can do stuff like "slowly turn LED from off to red, then switch
color to
white, then slowly turn it to yellow, then turn it off at once" with defined
speeds
for "slowly" and option of either linear on non-linear brightness ramping.
The last option might be a bit too much, but I believe we should support the
rest.
Yes, that's an interesting idea. It also turns out that trigger based
patterns could be also used for defining generic patterns for a group
of monochrome LEDs.
Yes, controlling monochrome LEDs synchronously is another task for
patterns. Actually, N900 uses that to control 6 keyboard backlight
LEDs synchronously... and yes, it would be somehow nice to preserve
this functionality.
--
Best regards,
Jacek Anaszewski
Re: [PATCH v2 0/2] vfs: Define new syscall getumask.
On Sun, Apr 17, 2016 at 06:57:36PM -0700, Josh Triplett wrote: > O_NOUMASK seems potentially useful to support implementation of umask > entirely in userspace, which also addresses thread-safety. A program > could read its process umask out at startup, handle umask entirely in > userspace (including for threads), and only interact with the system > umask after fork and before exec. I had a look at O_NOUMASK and there are a few problems: It's relatively easy to implement for open(2). A few filesystems implement their own open so I had to go into those filesystems and modify how they handle current_umask too. And FUSE support is tricky so I passed on that. The real problem is that mkdir/mkdirat/mknod/mknodat are affected by umask, but there is no convenient flags parameter to pass the O_NOUMASK flag. So I think the patch only half-solves the problem. I have a patch which needs a bit more testing, which I can post if you think that's helpful, but I don't think it would be acceptable in its current state. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org
Re: linux-next: build warning after merge of the regulator tree
On Mon, Apr 18, 2016 at 01:43:51PM +1000, Stephen Rothwell wrote: > In the future, please fix up all the current users of an interface > *before* marking it deprecated. All these extra warnings just muddy the > "real" warnings ... Ideally but sadly all the issues are in the graphics stack and while they seem relatively responsive to build issues there seems to be some strange way of working there which means that getting changes integrated or responses when issues like this come up has always been extremely difficult and unfortunately cut'n'paste also seems to be quite common (most of these look like they came from one place) so something to try to at least give people pause for thought when they introduce new issues seems sensible. I really wish I could figure out what's going on there. signature.asc Description: PGP signature
Re: [PATCH 2/3] sched: Correctly handle nohz ticks cpu load accounting
On Wed, Apr 13, 2016 at 03:56:51PM +0200, Frederic Weisbecker wrote:
> @@ -4645,11 +4674,11 @@ void cpu_load_update_nohz(int active)
> void cpu_load_update_active(struct rq *this_rq)
> {
> unsigned long load = weighted_cpuload(cpu_of(this_rq));
> - /*
> - * See the mess around cpu_load_update_idle() / cpu_load_update_nohz().
> - */
> - this_rq->last_load_update_tick = jiffies;
> - __cpu_load_update(this_rq, load, 1, 1);
> +
> + if (tick_nohz_tick_stopped())
> + cpu_load_update_nohz(this_rq, READ_ONCE(jiffies), load);
> + else
> + cpu_load_update_periodic(this_rq, load);
Considering it further, I wonder if needing it.
(Sorry if I missed something.)
Case 1. tickless -> (scheduler_tick) -> tickless
I am not sure for this case if the rq's load can be changed or not,
especially, if the rq's load can be changed *at this point*.
Please remind that the load[0] is set here.
Case 2. tickless -> (scheduler_tick) -> restart tick
Will be done by the tick restart routine when exiting irq.
-> no problem.
Case 3. tick -> (scheduler_tick) -> tickless
Same as before.
-> no problem.
Case 4. tick -> (scheduler_tick) -> tick
We can rely on regular schedule_tick().
-> no problem.
Re: [PATCH] omapfb: panel-sharp-ls037v7dw01: fix check of gpio_to_desc() return value
On 23/03/16 00:51, Vladimir Zapolskiy wrote:
> The change fixes a check of gpio_to_desc() return value, the function
> returns either a valid pointer to struct gpio_desc or NULL, this makes
> IS_ERR() check invalid and may lead to a NULL pointer dereference in
> runtime.
>
> Signed-off-by: Vladimir Zapolskiy
> ---
> .../fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c| 12
>
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git
> a/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
> b/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
> index abfd1f6..1954ec9 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c
> @@ -200,20 +200,16 @@ static struct omap_dss_driver sharp_ls_ops = {
> static int sharp_ls_get_gpio(struct device *dev, int gpio, unsigned long
> flags,
> char *desc, struct gpio_desc **gpiod)
> {
> - struct gpio_desc *gd;
> int r;
>
> - *gpiod = NULL;
> -
> r = devm_gpio_request_one(dev, gpio, flags, desc);
> - if (r)
> + if (r) {
> + *gpiod = NULL;
> return r == -ENOENT ? 0 : r;
> + }
>
> - gd = gpio_to_desc(gpio);
> - if (IS_ERR(gd))
> - return PTR_ERR(gd) == -ENOENT ? 0 : PTR_ERR(gd);
> + *gpiod = gpio_to_desc(gpio);
>
> - *gpiod = gd;
> return 0;
> }
>
>
Thanks, queued for 4.6 fixes.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V4 4/6] slim: qcom: Add Qualcomm Slimbus controller driver
On Fri, Apr 15, 2016 at 10:17:36AM -0600, Sagar Dharia wrote:
Please leave blank lines between paragraphs, it makes things much easier
to read than a wall of uninterrupted text.
> >>+ ret = devm_request_irq(&pdev->dev, dev->irq, msm_slim_interrupt,
> >>+ IRQF_TRIGGER_HIGH, "msm_slim_irq", dev);
> >>+ if (ret) {
> >>+ dev_err(&pdev->dev, "request IRQ failed\n");
> >>+ goto err_request_irq_failed;
> >>+ }
> >Are you sure this is safe and we don't deallocate things the interrupt
> >handler uses before we disable the interrupt?
> Since clock is not enabled before this step, we won't be getting any
> interrupts from HW at this stage.
No, that's not what I'm saying - I'm asking about the *disable* path on
remove.
signature.asc
Description: PGP signature
Re: [PATCH 1/3] ASoC: jack: Add a jack detect callback via codec
On Mon, Apr 18, 2016 at 04:17:30PM +0800, Xing Zheng wrote:
> This patch add a callback when a codec have the jack detect feature.
> +void snd_soc_jack_codec_detect(struct snd_soc_codec *codec,
> + struct snd_soc_jack *jack)
> +{
> + if (codec && codec->driver && codec->driver->detect_jack)
> + codec->driver->detect_jack(codec, jack);
> +}
> +EXPORT_SYMBOL_GPL(snd_soc_jack_codec_detect);
I've no idea what this is supposed to do sorry, you need a much better
changelog and probably also a restructuring of the code. This says it
is adding a callback but it doesn't do that, it adds an export of a
function that calls an operation in a driver with no explanation.
signature.asc
Description: PGP signature
[PATCH 2/2] drm/dsi: Implement DCS get display self diagnostic
Provide a small convenience wrapper that transmits
a DCS get_diagnostic_result command.
Signed-off-by: Vinay Simha BN
---
drivers/gpu/drm/drm_mipi_dsi.c | 25 +
include/drm/drm_mipi_dsi.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 2e032ea..e49b346 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -816,6 +816,31 @@ int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device
*dsi, u8 *mode)
EXPORT_SYMBOL(mipi_dsi_dcs_get_display_mode);
/**
+ * mipi_dsi_dcs_get_diagnostic_result() - query the display module's diagnostic
+ *result
+ * @dsi: DSI peripheral device
+ * @mode: return location for the display self diagnostic result
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_get_diagnostic_result(struct mipi_dsi_device *dsi, u8 *mode)
+{
+ ssize_t err;
+
+ err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DIAGNOSTIC_RESULT, mode,
+ sizeof(*mode));
+ if (err <= 0) {
+ if (err == 0)
+ err = -ENODATA;
+
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_get_diagnostic_result);
+
+/**
* mipi_dsi_dcs_get_pixel_format() - gets the pixel format for the RGB image
*data used by the interface
* @dsi: DSI peripheral device
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 48fcd65..61c375b 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -255,6 +255,7 @@ int mipi_dsi_dcs_nop(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_soft_reset(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device *dsi, u8 *mode);
int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device *dsi, u8 *mode);
+int mipi_dsi_dcs_get_diagnostic_result(struct mipi_dsi_device *dsi, u8 *mode);
int mipi_dsi_dcs_get_pixel_format(struct mipi_dsi_device *dsi, u8 *format);
int mipi_dsi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
--
2.1.2
[PATCH 1/2] drm/dsi: Implement DCS get display mode
Provide a small convenience wrapper that transmits
a DCS get_display_mode command.
Signed-off-by: Vinay Simha BN
---
drivers/gpu/drm/drm_mipi_dsi.c | 24
include/drm/drm_mipi_dsi.h | 1 +
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index f5d8083..2e032ea 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -792,6 +792,30 @@ int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device
*dsi, u8 *mode)
EXPORT_SYMBOL(mipi_dsi_dcs_get_power_mode);
/**
+ * mipi_dsi_dcs_get_display_mode() - query the display module's image mode
+ * @dsi: DSI peripheral device
+ * @mode: return location for the display image mode
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device *dsi, u8 *mode)
+{
+ ssize_t err;
+
+ err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DISPLAY_MODE, mode,
+ sizeof(*mode));
+ if (err <= 0) {
+ if (err == 0)
+ err = -ENODATA;
+
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_get_display_mode);
+
+/**
* mipi_dsi_dcs_get_pixel_format() - gets the pixel format for the RGB image
*data used by the interface
* @dsi: DSI peripheral device
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7a9840f..48fcd65 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -254,6 +254,7 @@ ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8
cmd, void *data,
int mipi_dsi_dcs_nop(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_soft_reset(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device *dsi, u8 *mode);
+int mipi_dsi_dcs_get_display_mode(struct mipi_dsi_device *dsi, u8 *mode);
int mipi_dsi_dcs_get_pixel_format(struct mipi_dsi_device *dsi, u8 *format);
int mipi_dsi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
--
2.1.2
Re: [PATCH] drm/rockchip: get rid of rockchip_drm_crtc_mode_config
Hi Mark,
On Mon, 18 Apr 2016 11:03:31 +0800, Mark Yao wrote:
> We need to take care of the vop status when use
> rockchip_drm_crtc_mode_config, if vop is disabled,
> the function would failed, that is terrible.
>
> Save connector type and output mode on drm_display_mode->private_flags
> at encoder mode_fixup, then we can configure the type and mode safely
> on crtc mode_set.
Since Rockchip is atomic, shouldn't this be using atomic_check hooks and
a subclassed crtc_state structure?
> Signed-off-by: Mark Yao
> ---
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 37 +++-
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 44 ++-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |5 +--
> drivers/gpu/drm/rockchip/inno_hdmi.c|5 +--
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 -
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 51
> +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h |6 +++
> 7 files changed, 69 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index a1d94d8..0344e52 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -97,7 +97,21 @@ rockchip_dp_drm_encoder_mode_fixup(struct drm_encoder
> *encoder,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> {
> - /* do nothing */
> + /*
> + * FIXME(Yakir): driver should configure the CRTC output video
> + * mode with the display information which indicated the monitor
> + * support colorimetry.
> + *
> + * But don't know why the CRTC driver seems could only output the
> + * RGBaaa rightly. For example, if connect the "innolux,n116bge"
> + * eDP screen, EDID would indicated that screen only accepted the
> + * 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
> + * screen would show a blue picture (RGB888 show a green picture).
> + * But if I configure CTRC to RGBaaa, and eDP driver still keep
> + * RGB666 input video mode, then screen would works prefect.
> + */
> + adjusted_mode->private_flags = ROCKCHIP_DSP_MODE(eDP, );
> +
> return true;
> }
>
> @@ -114,27 +128,6 @@ static void rockchip_dp_drm_encoder_enable(struct
> drm_encoder *encoder)
> int ret;
> u32 val;
>
> - /*
> - * FIXME(Yakir): driver should configure the CRTC output video
> - * mode with the display information which indicated the monitor
> - * support colorimetry.
> - *
> - * But don't know why the CRTC driver seems could only output the
> - * RGBaaa rightly. For example, if connect the "innolux,n116bge"
> - * eDP screen, EDID would indicated that screen only accepted the
> - * 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
> - * screen would show a blue picture (RGB888 show a green picture).
> - * But if I configure CTRC to RGBaaa, and eDP driver still keep
> - * RGB666 input video mode, then screen would works prefect.
> - */
> - ret = rockchip_drm_crtc_mode_config(encoder->crtc,
> - DRM_MODE_CONNECTOR_eDP,
> - ROCKCHIP_OUT_MODE_);
> - if (ret < 0) {
> - dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
> - return;
> - }
> -
> ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
> if (ret < 0)
> return;
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 7975158..49c4c72 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -875,11 +875,34 @@ static void dw_mipi_dsi_encoder_disable(struct
> drm_encoder *encoder)
> clk_disable_unprepare(dsi->pclk);
> }
>
> +static bool dw_mipi_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
> + const struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
> +
> + switch (dsi->format) {
> + case MIPI_DSI_FMT_RGB888:
> + adjusted_mode->private_flags = ROCKCHIP_DSP_MODE(DSI, P888);
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + adjusted_mode->private_flags = ROCKCHIP_DSP_MODE(DSI, P666);
> + break;
> + case MIPI_DSI_FMT_RGB565:
> + adjusted_mode->private_flags = ROCKCHIP_DSP_MODE(DSI, P565);
> + break;
> + default:
> + WARN_ON(1);
> + return false;
> + }
> +
> + return true;
> +}
> +
> static void dw_mipi_dsi_encoder_commit(struct
Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another
Hi Michał,
W dniu 07.04.2016 o 18:40, Michal Nazarewicz pisze:
On Thu, 7 Apr 2016, Michal Nazarewicz wrote:
This makes me suspect it’s not possible to link a function instance to
the same configuration twice, but now that I think about it, I’m not
quite sure what would happen if one did:
ln -s functions/mass_storage.0 configs/c.1/foo
ln -s functions/mass_storage.0 configs/c.1/bar
On Thu, Apr 07 2016, Alan Stern wrote:
Do you think it would be worthwhile to check for this possibility in
the driver and report an error?
I think this should be (if it isn’t already) blocked on configfs side.
I cannot see a legitimate use of such configuration and I wouldn’t be
surprised if other function drivers broke as well.
Sorry about late response.
The function responsible for verifying if a symlink can be made is
in drivers/usb/gadget/configfs.c: config_usb_cfg_link()
There is a comment from the author:
/*
* Make sure this function is from within our _this_ gadget and not
* from another gadget or a random directory.
* Also a function instance can only be linked once.
*/
This is the code fragment of interest:
list_for_each_entry(f, &cfg->func_list, list) {
if (f->fi == fi) {
ret = -EEXIST;
goto out;
}
}
AP
[PATCH v4 4/6] arm64: cpufeature: Check availability of AArch32
On ARMv8 support for AArch32 state is optional. Hence it is
not safe to check the AArch32 ID registers for sanity, which
could lead to false warnings. This patch makes sure that the
AArch32 state is implemented before we keep track of the 32bit
ID registers.
As per ARM ARM (D.1.21.2 - Support for Exception Levels and
Execution States, DDI0487A.h), checking the support for AArch32
at EL0 is good enough to check the support for AArch32 (i.e,
AArch32 at EL1 => AArch32 at EL0, but not vice versa).
Tested-by: Yury Norov
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/cpufeature.c | 86 ++--
arch/arm64/kernel/cpuinfo.c| 37 +
2 files changed, 67 insertions(+), 56 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index a067c31..cfc0cfd 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -435,22 +435,26 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
init_cpu_ftr_reg(SYS_ID_AA64MMFR2_EL1, info->reg_id_aa64mmfr2);
init_cpu_ftr_reg(SYS_ID_AA64PFR0_EL1, info->reg_id_aa64pfr0);
init_cpu_ftr_reg(SYS_ID_AA64PFR1_EL1, info->reg_id_aa64pfr1);
- init_cpu_ftr_reg(SYS_ID_DFR0_EL1, info->reg_id_dfr0);
- init_cpu_ftr_reg(SYS_ID_ISAR0_EL1, info->reg_id_isar0);
- init_cpu_ftr_reg(SYS_ID_ISAR1_EL1, info->reg_id_isar1);
- init_cpu_ftr_reg(SYS_ID_ISAR2_EL1, info->reg_id_isar2);
- init_cpu_ftr_reg(SYS_ID_ISAR3_EL1, info->reg_id_isar3);
- init_cpu_ftr_reg(SYS_ID_ISAR4_EL1, info->reg_id_isar4);
- init_cpu_ftr_reg(SYS_ID_ISAR5_EL1, info->reg_id_isar5);
- init_cpu_ftr_reg(SYS_ID_MMFR0_EL1, info->reg_id_mmfr0);
- init_cpu_ftr_reg(SYS_ID_MMFR1_EL1, info->reg_id_mmfr1);
- init_cpu_ftr_reg(SYS_ID_MMFR2_EL1, info->reg_id_mmfr2);
- init_cpu_ftr_reg(SYS_ID_MMFR3_EL1, info->reg_id_mmfr3);
- init_cpu_ftr_reg(SYS_ID_PFR0_EL1, info->reg_id_pfr0);
- init_cpu_ftr_reg(SYS_ID_PFR1_EL1, info->reg_id_pfr1);
- init_cpu_ftr_reg(SYS_MVFR0_EL1, info->reg_mvfr0);
- init_cpu_ftr_reg(SYS_MVFR1_EL1, info->reg_mvfr1);
- init_cpu_ftr_reg(SYS_MVFR2_EL1, info->reg_mvfr2);
+
+ if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0)) {
+ init_cpu_ftr_reg(SYS_ID_DFR0_EL1, info->reg_id_dfr0);
+ init_cpu_ftr_reg(SYS_ID_ISAR0_EL1, info->reg_id_isar0);
+ init_cpu_ftr_reg(SYS_ID_ISAR1_EL1, info->reg_id_isar1);
+ init_cpu_ftr_reg(SYS_ID_ISAR2_EL1, info->reg_id_isar2);
+ init_cpu_ftr_reg(SYS_ID_ISAR3_EL1, info->reg_id_isar3);
+ init_cpu_ftr_reg(SYS_ID_ISAR4_EL1, info->reg_id_isar4);
+ init_cpu_ftr_reg(SYS_ID_ISAR5_EL1, info->reg_id_isar5);
+ init_cpu_ftr_reg(SYS_ID_MMFR0_EL1, info->reg_id_mmfr0);
+ init_cpu_ftr_reg(SYS_ID_MMFR1_EL1, info->reg_id_mmfr1);
+ init_cpu_ftr_reg(SYS_ID_MMFR2_EL1, info->reg_id_mmfr2);
+ init_cpu_ftr_reg(SYS_ID_MMFR3_EL1, info->reg_id_mmfr3);
+ init_cpu_ftr_reg(SYS_ID_PFR0_EL1, info->reg_id_pfr0);
+ init_cpu_ftr_reg(SYS_ID_PFR1_EL1, info->reg_id_pfr1);
+ init_cpu_ftr_reg(SYS_MVFR0_EL1, info->reg_mvfr0);
+ init_cpu_ftr_reg(SYS_MVFR1_EL1, info->reg_mvfr1);
+ init_cpu_ftr_reg(SYS_MVFR2_EL1, info->reg_mvfr2);
+ }
+
}
static void update_cpu_ftr_reg(struct arm64_ftr_reg *reg, u64 new)
@@ -555,47 +559,51 @@ void update_cpu_features(int cpu,
info->reg_id_aa64pfr1,
boot->reg_id_aa64pfr1);
/*
-* If we have AArch32, we care about 32-bit features for compat. These
-* registers should be RES0 otherwise.
+* If we have AArch32, we care about 32-bit features for compat.
+* If the system doesn't support AArch32, don't update them.
*/
- taint |= check_update_ftr_reg(SYS_ID_DFR0_EL1, cpu,
+ if (id_aa64pfr0_32bit_el0(read_system_reg(SYS_ID_AA64PFR0_EL1)) &&
+ id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0)) {
+
+ taint |= check_update_ftr_reg(SYS_ID_DFR0_EL1, cpu,
info->reg_id_dfr0, boot->reg_id_dfr0);
- taint |= check_update_ftr_reg(SYS_ID_ISAR0_EL1, cpu,
+ taint |= check_update_ftr_reg(SYS_ID_ISAR0_EL1, cpu,
info->reg_id_isar0, boot->reg_id_isar0);
- taint |= check_update_ftr_reg(SYS_ID_ISAR1_EL1, cpu,
+ taint |= check_update_ftr_reg(SYS_ID_ISAR1_EL1, cpu,
info->reg_id_isar1, boot->reg_id_isar1);
- taint |= check_update_ftr_reg(SYS_ID_ISAR2_EL1, cpu,
+ taint |= check_update_ftr_reg(SYS_ID_ISAR2_EL1, cpu,
info->reg_id_isar2, boot->reg_id_isar2);
- taint |= check_update_ftr_reg(SYS_ID_ISAR3_EL1, cpu,
+ taint |
[PATCH v4 5/6] arm64: cpufeature: Track 32bit EL0 support
Add cpu_hwcap bit for keeping track of the support for 32bit EL0.
Tested-by: Yury Norov
Signed-off-by: Suzuki K Poulose
---
arch/arm64/include/asm/cpufeature.h |8 +++-
arch/arm64/kernel/cpufeature.c |9 +
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 7f64285..ca8fb4b 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -35,8 +35,9 @@
#define ARM64_ALT_PAN_NOT_UAO 10
#define ARM64_HAS_VIRT_HOST_EXTN 11
#define ARM64_WORKAROUND_CAVIUM_27456 12
+#define ARM64_HAS_32BIT_EL013
-#define ARM64_NCAPS13
+#define ARM64_NCAPS14
#ifndef __ASSEMBLY__
@@ -192,6 +193,11 @@ static inline bool cpu_supports_mixed_endian_el0(void)
return id_aa64mmfr0_mixed_endian_el0(read_cpuid(ID_AA64MMFR0_EL1));
}
+static inline bool system_supports_32bit_el0(void)
+{
+ return cpus_have_cap(ARM64_HAS_32BIT_EL0);
+}
+
static inline bool system_supports_mixed_endian_el0(void)
{
return
id_aa64mmfr0_mixed_endian_el0(read_system_reg(SYS_ID_AA64MMFR0_EL1));
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index cfc0cfd..4cd8f23 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -733,6 +733,15 @@ static const struct arm64_cpu_capabilities
arm64_features[] = {
.capability = ARM64_HAS_VIRT_HOST_EXTN,
.matches = runs_at_el2,
},
+ {
+ .desc = "32-bit EL0 Support",
+ .capability = ARM64_HAS_32BIT_EL0,
+ .matches = has_cpuid_feature,
+ .sys_reg = SYS_ID_AA64PFR0_EL1,
+ .sign = FTR_UNSIGNED,
+ .field_pos = ID_AA64PFR0_EL0_SHIFT,
+ .min_field_value = ID_AA64PFR0_EL0_32BIT_64BIT,
+ },
{},
};
--
1.7.9.5
[PATCH v4 6/6] arm64: compat: Check for AArch32 state
Make sure we have AArch32 state available for running COMPAT
binaries and also for switching the personality to PER_LINUX32.
Signed-off-by: Yury Norov
[ Added cap bit, checks for HWCAP, personality ]
Signed-off-by: Suzuki K Poulose
Tested-by: Yury Norov
---
arch/arm64/include/asm/elf.h |3 ++-
arch/arm64/kernel/cpufeature.c |7 +--
arch/arm64/kernel/sys.c| 10 ++
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 24ed037..7a09c48 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -177,7 +177,8 @@ typedef compat_elf_greg_t
compat_elf_gregset_t[COMPAT_ELF_NGREG];
/* AArch32 EABI. */
#define EF_ARM_EABI_MASK 0xff00
-#define compat_elf_check_arch(x) (((x)->e_machine == EM_ARM) && \
+#define compat_elf_check_arch(x) (system_supports_32bit_el0() && \
+((x)->e_machine == EM_ARM) && \
((x)->e_flags & EF_ARM_EABI_MASK))
#define compat_start_threadcompat_start_thread
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 4cd8f23..8c46621 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -982,7 +982,8 @@ void verify_local_cpu_capabilities(void)
verify_local_cpu_features(arm64_features);
verify_local_elf_hwcaps(arm64_elf_hwcaps);
- verify_local_elf_hwcaps(compat_elf_hwcaps);
+ if (system_supports_32bit_el0())
+ verify_local_elf_hwcaps(compat_elf_hwcaps);
}
static void __init setup_feature_capabilities(void)
@@ -999,7 +1000,9 @@ void __init setup_cpu_features(void)
/* Set the CPU feature capabilies */
setup_feature_capabilities();
setup_elf_hwcaps(arm64_elf_hwcaps);
- setup_elf_hwcaps(compat_elf_hwcaps);
+
+ if (system_supports_32bit_el0())
+ setup_elf_hwcaps(compat_elf_hwcaps);
/* Advertise that we have computed the system capabilities */
set_sys_caps_initialised();
diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c
index 75151aa..26fe8ea 100644
--- a/arch/arm64/kernel/sys.c
+++ b/arch/arm64/kernel/sys.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
asmlinkage long sys_mmap(unsigned long addr, unsigned long len,
unsigned long prot, unsigned long flags,
@@ -36,11 +37,20 @@ asmlinkage long sys_mmap(unsigned long addr, unsigned long
len,
return sys_mmap_pgoff(addr, len, prot, flags, fd, off >> PAGE_SHIFT);
}
+SYSCALL_DEFINE1(arm64_personality, unsigned int, personality)
+{
+ if (personality(personality) == PER_LINUX32 &&
+ !system_supports_32bit_el0())
+ return -EINVAL;
+ return sys_personality(personality);
+}
+
/*
* Wrappers to pass the pt_regs argument.
*/
asmlinkage long sys_rt_sigreturn_wrapper(void);
#define sys_rt_sigreturn sys_rt_sigreturn_wrapper
+#define sys_personalitysys_arm64_personality
#undef __SYSCALL
#define __SYSCALL(nr, sym) [nr] = sym,
--
1.7.9.5
