* Re: [PATCH v3 4/5] compress/zlib: support burst enqueue/dequeue
From: Verma, Shally @ 2018-07-23 17:14 UTC (permalink / raw)
To: Stephen Hemminger
Cc: pablo.de.lara.guarch@intel.com, dev@dpdk.org,
Athreya, Narayana Prasad, Challa, Mahipal, Gupta, Ashish,
Sahu, Sunila, Sahu, Sunila
In-Reply-To: <20180723095357.5a85b206@xeon-e3>
>-----Original Message-----
>From: Stephen Hemminger <stephen@networkplumber.org>
>Sent: 23 July 2018 22:24
>To: Verma, Shally <Shally.Verma@cavium.com>
>Cc: pablo.de.lara.guarch@intel.com; dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Challa,
>Mahipal <Mahipal.Challa@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
>Sahu, Sunila <Sunila.Sahu@cavium.com>
>Subject: Re: [dpdk-dev] [PATCH v3 4/5] compress/zlib: support burst enqueue/dequeue
>
>External Email
>
>On Sat, 21 Jul 2018 23:47:48 +0530
>Shally Verma <shally.verma@caviumnetworks.com> wrote:
>
>> -/** Parse comp xform and set private xform/stream parameters */
>> +/** Compute next mbuf in the list, assign data buffer and length,
>> + * returns 0 if mbuf is NULL
>> + */
>> +#define COMPUTE_BUF(mbuf, data, len) \
>> + ((mbuf = mbuf->next) ? \
>> + (data = rte_pktmbuf_mtod(mbuf, uint8_t *)), \
>> + (len = rte_pktmbuf_data_len(mbuf)) : 0)
>> +
>
>Could this be an inline not a macro?
[Shally] Again what goes in favour of inline here? Just curious to know if DPDK has any preferred guidelines regarding this?
Thanks
Shally
^ permalink raw reply
* [PATCH 8/9] fetch2/git: move generation of git source name into own method
From: Urs Fässler @ 2018-07-23 15:42 UTC (permalink / raw)
To: bitbake-devel
In-Reply-To: <20180723154259.9076-1-urs.fassler@bbv.ch>
Signed-off-by: Urs Fässler <urs.fassler@bbv.ch>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
---
lib/bb/fetch2/git.py | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/lib/bb/fetch2/git.py b/lib/bb/fetch2/git.py
index 7f7951f7..f9e31d2b 100644
--- a/lib/bb/fetch2/git.py
+++ b/lib/bb/fetch2/git.py
@@ -248,17 +248,7 @@ class Git(FetchMethod):
ud.unresolvedrev[name] = ud.revisions[name]
ud.revisions[name] = self.latest_revision(ud, d, name)
- gitsrcname = '%s%s' % (ud.host.replace(':', '.'), ud.path.replace('/', '.').replace('*', '.'))
- if gitsrcname.startswith('.'):
- gitsrcname = gitsrcname[1:]
-
- # for rebaseable git repo, it is necessary to keep mirror tar ball
- # per revision, so that even the revision disappears from the
- # upstream repo in the future, the mirror will remain intact and still
- # contains the revision
- if ud.rebaseable:
- for name in ud.names:
- gitsrcname = gitsrcname + '_' + ud.revisions[name]
+ gitsrcname = self.__build_git_source_name(ud.host, ud.path, ud.rebaseable, ud.names, ud.revisions)
dl_dir = d.getVar("DL_DIR")
gitdir = d.getVar("GITDIR") or (dl_dir + "/git2")
@@ -295,6 +285,22 @@ class Git(FetchMethod):
ud.fullshallow = os.path.join(dl_dir, ud.shallowtarball)
ud.mirrortarballs.insert(0, ud.shallowtarball)
+ @staticmethod
+ def __build_git_source_name(host, path, rebaseable, names, revisions):
+ gitsrcname = '%s%s' % (host.replace(':', '.'), path.replace('/', '.').replace('*', '.'))
+ if gitsrcname.startswith('.'):
+ gitsrcname = gitsrcname[1:]
+
+ # for rebaseable git repo, it is necessary to keep mirror tar ball
+ # per revision, so that even the revision disappears from the
+ # upstream repo in the future, the mirror will remain intact and still
+ # contains the revision
+ if rebaseable:
+ for name in names:
+ gitsrcname = gitsrcname + '_' + revisions[name]
+
+ return gitsrcname
+
def localpath(self, ud, d):
return ud.clonedir
--
2.18.0
^ permalink raw reply related
* [PATCH 10/10] drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic
From: Deepak Singh Rawat @ 2018-07-23 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180720211509.23605-11-alexandru-cosmin.gheorghe@arm.com>
Hi Alexandru,
Thanks for the patch, for the vmwgfx part:
Reviewed-by: Deepak Rawat <drawat@vmware.com>
>
> Signed-off-by: Alexandru Gheorghe <alexandru-
> cosmin.gheorghe at arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 466336b34fff..1e0fb3c79b50 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -720,9 +720,7 @@ void vmw_du_plane_reset(struct drm_plane *plane)
> return;
> }
>
> - plane->state = &vps->base;
> - plane->state->plane = plane;
> - plane->state->rotation = DRM_MODE_ROTATE_0;
> + __drm_atomic_helper_plane_reset(plane, &vps->base);
> }
>
>
> --
> 2.18.0
>
^ permalink raw reply
* RE: [PATCH 10/10] drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic
From: Deepak Singh Rawat @ 2018-07-23 17:16 UTC (permalink / raw)
To: Alexandru Gheorghe
Cc: alexandre.belloni@bootlin.com, airlied@linux.ie,
liviu.dudau@arm.com, dri-devel@lists.freedesktop.org,
laurent.pinchart@ideasonboard.com, Thomas Hellstrom,
krzk@kernel.org, maxime.ripard@bootlin.com, wens@csie.org,
kgene@kernel.org, malidp@foss.arm.com, linux-graphics-maintainer,
sunpeng.li@amd.com, boris.brezillon@bootlin.com,
linux-samsung-soc@vger.kernel.org, nd@arm.com, Tony.Cheng@amd.com,
linux-arm-kernel
In-Reply-To: <20180720211509.23605-11-alexandru-cosmin.gheorghe@arm.com>
Hi Alexandru,
Thanks for the patch, for the vmwgfx part:
Reviewed-by: Deepak Rawat <drawat@vmware.com>
>
> Signed-off-by: Alexandru Gheorghe <alexandru-
> cosmin.gheorghe@arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 466336b34fff..1e0fb3c79b50 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -720,9 +720,7 @@ void vmw_du_plane_reset(struct drm_plane *plane)
> return;
> }
>
> - plane->state = &vps->base;
> - plane->state->plane = plane;
> - plane->state->rotation = DRM_MODE_ROTATE_0;
> + __drm_atomic_helper_plane_reset(plane, &vps->base);
> }
>
>
> --
> 2.18.0
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.19
From: Geert Uytterhoeven @ 2018-07-23 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMh09Do+Yv-C+4hE0KdShajr0hVRfLEPmeoH0AmM5kVAmw@mail.gmail.com>
Hi Olof,
On Mon, Jul 23, 2018 at 6:22 PM Olof Johansson <olof@lixom.net> wrote:
> On Mon, Jul 23, 2018 at 2:11 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> >> > * Set CONFIG_LOCALVERSION to shmobile_defconfig
> >> >
> >> > This follows what appears to be common practice in defconfigs
> >> > and allows easier management of the kernel flavour at run-time.
> >>
> >> I replied to the multi-versions of defconfig for this patch -- it's not a good
> >> way to solve the problem of detecting config at runtime. Please drop this
> >> patch. See:
> >>
> >> https://lore.kernel.org/lkml/CAOesGMgkU6yBRpAsED2fPyuAo9Tc=YprndGdkmBVrc+0783VwQ at mail.gmail.com/
> >
> > One more comment to the rescue: it does complicate regression testing,
> > as the test software running on the DUT has no easy way to distinguish
> > between e.g. shmobile_defconfig and multi_v7_defconfig (and whatever
> > other board-specific configs I use for testing).
> > Yes, I can have these as local patches in my tree (of course I already have ;-),
> > but when bisecting, I have to remember to (un)apply them in every step.
>
> It looks like scripts/setlocalversion will look for files named
> localversion* in the directory you build in, git won't touch the file
> so you don't have to re-apply it every time.
Thanks a lot, works fine!
I didn't know about that; I started using CONFIG_LOCALVERSION during the
version control dark ages.
Since I use different output directories for different builds anyway, the
file won't ever be removed by git.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
^ permalink raw reply
* Re: [PATCH 3/4] perf/x86/intel/ds: Handle PEBS overflow for fixed counters
From: Liang, Kan @ 2018-07-23 17:15 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tglx, mingo, linux-kernel, acme, alexander.shishkin,
vincent.weaver, jolsa, ak
In-Reply-To: <e56be489-3f66-8f27-37e4-77b12c1c99f4@linux.intel.com>
On 7/23/2018 12:56 PM, Liang, Kan wrote:
>
>
> On 7/23/2018 12:21 PM, Peter Zijlstra wrote:
>> On Mon, Jul 23, 2018 at 04:59:44PM +0200, Peter Zijlstra wrote:
>>> On Thu, Mar 08, 2018 at 06:15:41PM -0800, kan.liang@linux.intel.com
>>> wrote:
>>>> diff --git a/arch/x86/events/intel/core.c
>>>> b/arch/x86/events/intel/core.c
>>>> index ef47a418d819..86149b87cce8 100644
>>>> --- a/arch/x86/events/intel/core.c
>>>> +++ b/arch/x86/events/intel/core.c
>>>> @@ -2280,7 +2280,10 @@ static int intel_pmu_handle_irq(struct
>>>> pt_regs *regs)
>>>> * counters from the GLOBAL_STATUS mask and we always process
>>>> PEBS
>>>> * events via drain_pebs().
>>>> */
>>>> - status &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK);
>>>> + if (x86_pmu.flags & PMU_FL_PEBS_ALL)
>>>> + status &= ~(cpuc->pebs_enabled & EXTENDED_PEBS_COUNTER_MASK);
>>>> + else
>>>> + status &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK);
>>>> /*
>>>> * PEBS overflow sets bit 62 in the global status register
>>>
>>> Doesn't this re-introduce the problem fixed in commit fd583ad1563be,
>>> where pebs_enabled:32-34 are PEBS Load Latency, instead of fixed
>>> counters?
>>
>> Also, since they 'fixed' that conflict, the PEBS_ALL version could be:
>>
>> state &= cpuc->pebs_enabled;
>>
>> Right?
>
Here, we need to clear the bit for PEBS counters.
For PEBS_ALL version, it should be
status &= ~cpuc->pebs_enabled;
Thanks,
Kan
^ permalink raw reply
* Re: [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree
From: Andrii Anisov @ 2018-07-23 17:14 UTC (permalink / raw)
To: Stefano Stabellini, julien.grall; +Cc: andrew.cooper3, jbeulich, xen-devel
In-Reply-To: <alpine.DEB.2.10.1807061523160.13502@sstabellini-ThinkPad-X260>
Hello Stefano,
On 07.07.18 02:11, Stefano Stabellini wrote:
> The device tree based boot protocol is extended to carry information
> about DomUs. Based on that information, Xen creates and starts one or
> more DomUs.
Please consider also status monitoring and restarting for those domains.
> DomUs created this way don't have access to xenstore for the
> moment. This is actually OK, because this is meant for mission critical
> applications that typically only access directly assigned devices. They
> cannot tolerate interference or increased IRQ latency due to PV
> protocols.
But even a mission critical application does exchange some information
with other entities in the system. So they would need interdomain
communication anyway (i.e. built with event channels and shared pages, etc.)
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree
From: Julien Grall @ 2018-07-23 17:13 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: andrew.cooper3, nd, andrii_anisov, jbeulich, xen-devel
In-Reply-To: <alpine.DEB.2.10.1807181047500.21200@sstabellini-ThinkPad-X260>
On 18/07/18 18:48, Stefano Stabellini wrote:
> On Wed, 18 Jul 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 13/07/18 21:54, Stefano Stabellini wrote:
>>> On Thu, 12 Jul 2018, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> Would it be possible to provide a branch with the patch applied? It would
>>>> be
>>>> nice to have that for every version, so I can easily know on which version
>>>> of
>>>> you are based and avoid spending time trying to apply it :).
>>>
>>> Makes sense, I'll do from next time
>>
>> Could you provide one from this version? So I can review some of your patches
>> more easily.
>
> http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git dom0less-v2
Thanks. I will have a look at the vpl011 patches. I think the rest is
either reviewed or will require changes based on other comments.
Let me know if I missed anything.
Cheers,
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] firmware: vpd: Fix section enabled flag on vpd_section_destroy
From: Guenter Roeck @ 2018-07-23 17:13 UTC (permalink / raw)
To: Anton Vasilyev
Cc: Greg Kroah-Hartman, Dmitry Torokhov, Samuel Holland, Pan Bian,
linux-kernel, ldv-project
In-Reply-To: <20180723164857.24460-1-vasilyev@ispras.ru>
On Mon, Jul 23, 2018 at 07:48:57PM +0300, Anton Vasilyev wrote:
> static struct ro_vpd and rw_vpd are initialized by vpd_sections_init()
> in vpd_probe() based on header's ro and rw sizes.
> In vpd_remove() vpd_section_destroy() performs deinitialization based
> on enabled flag, which is set to true by vpd_sections_init().
> This leads to call of vpd_section_destroy() on already destroyed section
> for probe-release-probe-release sequence if first probe performs
> ro_vpd initialization and second probe does not initialize it.
>
I am not sure if the situation described can be seen in the first place.
The second probe would only not perform ro_vpd initialization if it fails
prior to that, ie if it fails to allocate memory or if there is a
consistency problem. In that case the remove function would not be called.
However, there is a problem in the code: A partially failed probe will
leave the system in inconsistent state. Example: ro section initializes,
rw section fails to initialize. The probe will fail, but the ro section
will not be destroyed, its sysfs attributes still exist, and its memory
is still mapped. It would make more sense to fix _that_ problem.
Essentially, vpd_sections_init() should clean up after itself after it
fails to initialize a section.
Note that I am not convinced that the "enabled" flag is needed in the first
place. It is only relevant if vpd_section_destroy() is called, which only
happens from the remove function. The remove function is only called if the
probe function succeeded. In that case it is always set for both sections.
Thanks,
Guenter
> The patch adds changing enabled flag on vpd_section_destroy.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
> ---
> drivers/firmware/google/vpd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/firmware/google/vpd.c b/drivers/firmware/google/vpd.c
> index e9db895916c3..5347c17c7108 100644
> --- a/drivers/firmware/google/vpd.c
> +++ b/drivers/firmware/google/vpd.c
> @@ -246,6 +246,7 @@ static int vpd_section_destroy(struct vpd_section *sec)
> sysfs_remove_bin_file(vpd_kobj, &sec->bin_attr);
> kfree(sec->raw_name);
> memunmap(sec->baseaddr);
> + sec->enabled = false;
> }
>
> return 0;
> --
> 2.18.0
>
^ permalink raw reply
* [PATCH 5/5] ARM: dts: exynos: configure midas SD card CD pin
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-6-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:53PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we need to disable the SoC's
> internal pull down resistor to allow it to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs
From: Lyude Paul @ 2018-07-23 17:13 UTC (permalink / raw)
To: gregkh; +Cc: bskeggs, stable, David Airlie, dri-devel, nouveau, linux-kernel
In-Reply-To: <153227752119282@kroah.com>
commit eb493fbc150f4a28151ae1ee84f24395989f3600 upstream
Currently nouveau doesn't actually expose the state debugfs file that's
usually provided for any modesetting driver that supports atomic, even
if nouveau is loaded with atomic=1. This is due to the fact that the
standard debugfs files that DRM creates for atomic drivers is called
when drm_get_pci_dev() is called from nouveau_drm.c. This happens well
before we've initialized the display core, which is currently
responsible for setting the DRIVER_ATOMIC cap.
So, move the atomic option into nouveau_drm.c and just add the
DRIVER_ATOMIC cap whenever it's enabled on the kernel commandline. This
shouldn't cause any actual issues, as the atomic ioctl will still fail
as expected even if the display core doesn't disable it until later in
the init sequence. This also provides the added benefit of being able to
use the state debugfs file to check the current display state even if
clients aren't allowed to modify it through anything other than the
legacy ioctls.
Additionally, disable the DRIVER_ATOMIC cap in nv04's display core, as
this was already disabled there previously.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 +++
drivers/gpu/drm/nouveau/nouveau_drm.c | 7 +++++++
drivers/gpu/drm/nouveau/nv50_display.c | 6 ------
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 501d2d290e9c..70dce544984e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -55,6 +55,9 @@ nv04_display_create(struct drm_device *dev)
nouveau_display(dev)->init = nv04_display_init;
nouveau_display(dev)->fini = nv04_display_fini;
+ /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */
+ dev->driver->driver_features &= ~DRIVER_ATOMIC;
+
nouveau_hw_save_vga_fonts(dev, 1);
nv04_crtc_create(dev, 0);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
index bbbf353682e1..21d28e812963 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -79,6 +79,10 @@ MODULE_PARM_DESC(modeset, "enable driver (default: auto, "
int nouveau_modeset = -1;
module_param_named(modeset, nouveau_modeset, int, 0400);
+MODULE_PARM_DESC(atomic, "Expose atomic ioctl (default: disabled)");
+static int nouveau_atomic = 0;
+module_param_named(atomic, nouveau_atomic, int, 0400);
+
MODULE_PARM_DESC(runpm, "disable (0), force enable (1), optimus only default (-1)");
static int nouveau_runtime_pm = -1;
module_param_named(runpm, nouveau_runtime_pm, int, 0400);
@@ -501,6 +505,9 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
pci_set_master(pdev);
+ if (nouveau_atomic)
+ driver_pci.driver_features |= DRIVER_ATOMIC;
+
ret = drm_get_pci_dev(pdev, pent, &driver_pci);
if (ret) {
nvkm_device_del(&device);
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c
index bc5c4f2402b4..abe297fda046 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4441,10 +4441,6 @@ nv50_display_destroy(struct drm_device *dev)
kfree(disp);
}
-MODULE_PARM_DESC(atomic, "Expose atomic ioctl (default: disabled)");
-static int nouveau_atomic = 0;
-module_param_named(atomic, nouveau_atomic, int, 0400);
-
int
nv50_display_create(struct drm_device *dev)
{
@@ -4469,8 +4465,6 @@ nv50_display_create(struct drm_device *dev)
disp->disp = &nouveau_display(dev)->disp;
dev->mode_config.funcs = &nv50_disp_func;
dev->driver->driver_features |= DRIVER_PREFER_XBGR_30BPP;
- if (nouveau_atomic)
- dev->driver->driver_features |= DRIVER_ATOMIC;
/* small shared memory area we use for notifiers and semaphores */
ret = nouveau_bo_new(&drm->client, 4096, 0x1000, TTM_PL_FLAG_VRAM,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 5/5] ARM: dts: exynos: configure midas SD card CD pin
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Rob Herring, Mark Rutland, Kukjin Kim,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20180721125128.31498-6-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:53PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we need to disable the SoC's
> internal pull down resistor to allow it to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 4/5] ARM: dts: exynos: configure max77686 IRQ pin on midas
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-5-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:52PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we need to disable the
> SoC's internal pull-down.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/5] ARM: dts: exynos: configure max77686 IRQ pin on midas
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Rob Herring, Mark Rutland, Kukjin Kim,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20180721125128.31498-5-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:52PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we need to disable the
> SoC's internal pull-down.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps
From: David Hildenbrand @ 2018-07-23 17:12 UTC (permalink / raw)
To: Vlastimil Babka, linux-mm
Cc: linux-kernel, Andrew Morton, Baoquan He, Dave Young,
Greg Kroah-Hartman, Hari Bathini, Huang Ying, Kirill A. Shutemov,
Marc-André Lureau, Matthew Wilcox, Michal Hocko,
Michal Hocko, Miles Chen, Pavel Tatashin, Petr Tesarik
In-Reply-To: <9f46f0ed-e34c-73be-60ca-c892fb19ed08@suse.cz>
On 23.07.2018 13:45, Vlastimil Babka wrote:
> On 07/20/2018 02:34 PM, David Hildenbrand wrote:
>> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
>> So reserved pages might be access by dump tools although nobody except
>> the owner should touch them.
>
> Are you sure about that? Or maybe I understand wrong. Maybe it changed
> recently, but IIRC pages that are backing memmap (struct pages) are also
> PG_reserved. And you definitely do want those in the dump.
I proposed a new flag/value to mask pages that are logically offline but
Michal wanted me to go into this direction.
While we can special case struct pages in dump tools ("we have to
read/interpret them either way, so we can also dump them"), it smells
like my original attempt was cleaner. Michal?
>
>> This is relevant in virtual environments where we soon might want to
>> report certain reserved pages to the hypervisor and they might no longer
>> be accessible - what already was documented for reserved pages a long
>> time ago ("might not even exist").
>>
>> David Hildenbrand (2):
>> mm: clarify semantics of reserved pages
>> kdump: include PG_reserved value in VMCOREINFO
>>
>> include/linux/page-flags.h | 4 ++--
>> kernel/crash_core.c | 1 +
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
>
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH 3/5] ARM: dts: exynos: add pinctrl for midas fuelgauge irq pin
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-4-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:51PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we should disable the SoC's
> pull down resistor in order for the interrupt to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/5] ARM: dts: exynos: add pinctrl for midas fuelgauge irq pin
From: Krzysztof Kozlowski @ 2018-07-23 17:13 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Rob Herring, Mark Rutland, Kukjin Kim,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20180721125128.31498-4-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:51PM +1000, Simon Shields wrote:
> This pin is externally pulled up, so we should disable the SoC's
> pull down resistor in order for the interrupt to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/5] ARM: dts: exynos: add pinctrl config for midas keys
From: Krzysztof Kozlowski @ 2018-07-23 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-3-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:50PM +1000, Simon Shields wrote:
> This pins are externally pulled up, and so we should explicitly
> configure them to disable the SoC-internal pull-downs. Previously
> we relied on the bootloader doing this in order to allow the buttons
> to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] ARM: dts: exynos: add pinctrl config for midas keys
From: Krzysztof Kozlowski @ 2018-07-23 17:12 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Rob Herring, Mark Rutland, Kukjin Kim,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20180721125128.31498-3-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:50PM +1000, Simon Shields wrote:
> This pins are externally pulled up, and so we should explicitly
> configure them to disable the SoC-internal pull-downs. Previously
> we relied on the bootloader doing this in order to allow the buttons
> to function properly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/5] ARM: dts: exynos: add max77693 pinctrl config for midas
From: Krzysztof Kozlowski @ 2018-07-23 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180721125128.31498-2-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:49PM +1000, Simon Shields wrote:
> Currently, we assume that the bootloader has correctly configured
> the interrupt pin for max77693. This might not actually be the case -
> so it's better to configure it explicitly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/5] ARM: dts: exynos: add max77693 pinctrl config for midas
From: Krzysztof Kozlowski @ 2018-07-23 17:12 UTC (permalink / raw)
To: Simon Shields
Cc: linux-samsung-soc, Rob Herring, Mark Rutland, Kukjin Kim,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20180721125128.31498-2-simon@lineageos.org>
On Sat, Jul 21, 2018 at 10:50:49PM +1000, Simon Shields wrote:
> Currently, we assume that the bootloader has correctly configured
> the interrupt pin for max77693. This might not actually be the case -
> so it's better to configure it explicitly.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> arch/arm/boot/dts/exynos4412-midas.dtsi | 7 +++++++
> 1 file changed, 7 insertions(+)
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 00/15] xen/arm: Bunch of clean-up/improvement
From: Julien Grall @ 2018-07-23 17:12 UTC (permalink / raw)
To: xen-devel; +Cc: sstabellini
In-Reply-To: <20180716172712.20294-1-julien.grall@arm.com>
Ping?
Cheers,
On 16/07/18 18:26, Julien Grall wrote:
> Hi all,
>
> This is patch series is a bunch of clean-up/improvement I collected while
> working on the P2M and trap subsystems.
>
> Cheers,
>
> Julien Grall (15):
> xen/arm: cpregs: Allow HSR_CPREG* to receive more than 1 parameter
> xen/arm: cpregs: Fix typo in the documentation of TTBCR
> xen/arm: Introduce helpers to clear/flags flags in HCR_EL2
> xen/arm: p2m: Reduce the locking section in get_page_from_gva
> xen/arm: p2m: Limit call to mem access code use in get_page_from_gva
> xen/arm: Rework lpae_mapping
> xen/arm: Rework lpae_table
> xen/arm: Rename lpae_valid to lpae_is_valid
> xen/arm: guest_walk: Use lpae_is_mapping to simplify the code
> xen/arm: Introduce helpers to get/set an MFN from/to an LPAE entry
> xen/arm: Allow lpae_is_{table, mapping} helpers to work on invalid
> entry
> xen/arm: p2m: Rename ret to mfn in p2m_lookup
> xen/arm: p2m: Introduce a new variable removing_mapping in
> __p2m_set_entry
> xen/arm: guest_walk_tables: Switch the return to bool
> xen/arm: traps: Move the implementation of GUEST_BUG_ON in traps.h
>
> xen/arch/arm/guest_walk.c | 54 +++++++++----------
> xen/arch/arm/mem_access.c | 2 +-
> xen/arch/arm/mm.c | 18 +++----
> xen/arch/arm/p2m.c | 110 ++++++++++++++++++++++++---------------
> xen/arch/arm/traps.c | 27 +---------
> xen/include/asm-arm/cpregs.h | 6 +--
> xen/include/asm-arm/guest_walk.h | 8 +--
> xen/include/asm-arm/lpae.h | 27 +++++-----
> xen/include/asm-arm/processor.h | 18 +++++++
> xen/include/asm-arm/traps.h | 24 +++++++++
> 10 files changed, 168 insertions(+), 126 deletions(-)
>
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v2 10/12] sched/core: uclamp: use TG's clamps to restrict Task's clamps
From: Suren Baghdasaryan @ 2018-07-23 17:11 UTC (permalink / raw)
To: Patrick Bellasi
Cc: linux-kernel, linux-pm, Ingo Molnar, Peter Zijlstra, Tejun Heo,
Rafael J . Wysocki, Viresh Kumar, Vincent Guittot, Paul Turner,
Dietmar Eggemann, Morten Rasmussen, Juri Lelli, Todd Kjos,
Joel Fernandes, Steve Muckle
In-Reply-To: <20180723154025.GF2683@e110439-lin>
On Mon, Jul 23, 2018 at 8:40 AM, Patrick Bellasi
<patrick.bellasi@arm.com> wrote:
> On 21-Jul 20:05, Suren Baghdasaryan wrote:
>> On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi
>> <patrick.bellasi@arm.com> wrote:
>> > When a task's util_clamp value is configured via sched_setattr(2), this
>> > value has to be properly accounted in the corresponding clamp group
>> > every time the task is enqueued and dequeued. When cgroups are also in
>> > use, per-task clamp values have to be aggregated to those of the CPU's
>> > controller's Task Group (TG) in which the task is currently living.
>> >
>> > Let's update uclamp_cpu_get() to provide aggregation between the task
>> > and the TG clamp values. Every time a task is enqueued, it will be
>> > accounted in the clamp_group which defines the smaller clamp between the
>> > task specific value and its TG value.
>>
>> So choosing smallest for both UCLAMP_MIN and UCLAMP_MAX means the
>> least boosted value and the most clamped value between syscall and TG
>> will be used.
>
> Right
>
>> My understanding is that boost means "at least this much" and clamp
>> means "at most this much".
>
> Right
>
>> So to satisfy both TG and syscall requirements I think you would
>> need to choose the largest value for UCLAMP_MIN and the smallest one
>> for UCLAMP_MAX, meaning the most boosted and most clamped range.
>> Current implementation choses the least boosted value, so
>> effectively one of the UCLAMP_MIN requirements (either from TG or
>> from syscall) are being ignored... Could you please clarify why
>> this choice is made?
>
> The TG values are always used to specify a _restriction_ on
> task-specific values.
>
> Thus, if you look or example at the CPU mask for a task, you can have
> a task with affinity to CPUs 0-1, currently running on a cgroup with
> cpuset.cpus=0... then the task can run only on CPU 0 (althought its
> affinity includes CPU1 too).
>
> Same we do here: if a task has util_min=10, but it's running in a
> cgroup with cpu.util_min=0, then it will not be boosted.
>
> IOW, this allows to implement a "nice" policy at task level, where a
> task (via syscall) can decide to be less boosted with respect to its
> group but never more boosted. The same task can also decide to be more
> clamped, but not less clamped then its current group.
>
The fact that boost means "at least this much" to me seems like we can
safely choose higher CPU bandwidth (as long as it's lower than
UCLAMP_MAX) but from your description sounds like TG's UCLAMP_MIN
means "at most this much boost" and it's not safe to use CPU bandwidth
higher than TG's UCLAMP_MIN. So instead of specifying min CPU
bandwidth for a task it specifies the max allowed boost. Seems like a
discrepancy to me but maybe there are compelling usecases when this
behavior is necessary? In that case would be good to spell them out to
explain why this choice is made.
> [...]
>
>> > @@ -982,18 +989,30 @@ static inline void uclamp_cpu_get_id(struct task_struct *p,
>> > int clamp_value;
>> > int group_id;
>> >
>> > - /* No task specific clamp values: nothing to do */
>> > group_id = p->uclamp[clamp_id].group_id;
>> > + clamp_value = p->uclamp[clamp_id].value;
>> > +#ifdef CONFIG_UCLAMP_TASK_GROUP
>> > + /* Use TG's clamp value to limit task specific values */
>> > + if (group_id == UCLAMP_NONE ||
>> > + clamp_value >= task_group(p)->uclamp[clamp_id].value) {
>>
>> Not a big deal but do you need to override if (clamp_value ==
>> task_group(p)->uclamp[clamp_id].value)? Maybe:
>> - clamp_value >= task_group(p)->uclamp[clamp_id].value) {
>> + clamp_value > task_group(p)->uclamp[clamp_id].value) {
>
> Good point, yes... the override is not really changing anything here.
> Will fix this!
>
>> > + clamp_value = task_group(p)->uclamp[clamp_id].value;
>> > + group_id = task_group(p)->uclamp[clamp_id].group_id;
>> > + }
>> > +#else
>> > + /* No task specific clamp values: nothing to do */
>> > if (group_id == UCLAMP_NONE)
>> > return;
>> > +#endif
>> >
>> > /* Reference count the task into its current group_id */
>> > uc_grp = &rq->uclamp.group[clamp_id][0];
>> > uc_grp[group_id].tasks += 1;
>> >
>> > + /* Track the effective clamp group */
>> > + p->uclamp_group_id[clamp_id] = group_id;
>> > +
>> > /* Force clamp update on idle exit */
>> > uc_cpu = &rq->uclamp;
>> > - clamp_value = p->uclamp[clamp_id].value;
>> > if (unlikely(uc_cpu->flags & UCLAMP_FLAG_IDLE)) {
>> > if (clamp_id == UCLAMP_MAX)
>> > uc_cpu->flags &= ~UCLAMP_FLAG_IDLE;
>
> [...]
>
> --
> #include <best/regards.h>
>
> Patrick Bellasi
^ permalink raw reply
* [Intel-wired-lan] [jkirsher/next-queue PATCH 2/2] ixgbe: Refactor queue disable logic to take completion time into account
From: Alexander Duyck @ 2018-07-23 17:10 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <ab26e694-6c7c-7e70-42f3-646939708ee2@oracle.com>
On Mon, Jul 23, 2018 at 9:34 AM, Shannon Nelson
<shannon.nelson@oracle.com> wrote:
> On 7/20/2018 3:29 PM, Alexander Duyck wrote:
>>
>> This change is meant to allow us to take completion time into account when
>> disabling queues. Previously we were just working with hard coded values
>> for how long we should wait. This worked fine for the standard case where
>> completion timeout was operating in the 50us to 50ms range, however on
>> platforms that have higher completion timeout times this was resulting in
>> Rx queues disable messages being displayed as we weren't waiting long
>> enough for outstanding Rx DMA completions.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> ---
>
>
> [...]
>
>
>> +
>> +void ixgbe_disable_tx(struct ixgbe_adapter *adapter)
>> +{
>> + unsigned long wait_delay, delay_interval;
>> + struct ixgbe_hw *hw = &adapter->hw;
>> + int i, wait_loop;
>> + u32 txdctl;
>> +
>> + if (ixgbe_removed(hw->hw_addr))
>> + return;
>> +
>> + /* disable all enabled Tx queues */
>> + for (i = 0; i < adapter->num_tx_queues; i++) {
>> + struct ixgbe_ring *ring = adapter->tx_ring[i];
>> + u8 reg_idx = ring->reg_idx;
>> +
>> + IXGBE_WRITE_REG(hw, IXGBE_TXDCTL(reg_idx),
>> IXGBE_TXDCTL_SWFLSH);
>> + }
>> +
>> + /* disable all enabled XDP Tx queues */
>> + for (i = 0; i < adapter->num_xdp_queues; i++) {
>> + struct ixgbe_ring *ring = adapter->xdp_ring[i];
>> + u8 reg_idx = ring->reg_idx;
>> +
>> + IXGBE_WRITE_REG(hw, IXGBE_TXDCTL(reg_idx),
>> IXGBE_TXDCTL_SWFLSH);
>> + }
>> +
>> + /* If the link is now up there shouldn't be much in the way of
>
>
> I think you mean "not" up rather than "now" up, which has the opposite
> meaning and could be a bit confusing.
Yeah, that is a typo.
>
>> + * pending transactions. Those that are left will be flushed out
>> + * when the reset logic goes through the flush sequence to clean
>> out
>> + * the pending Tx transactions.
>> + */
>> + if (!(IXGBE_READ_REG(hw, IXGBE_LINKS) & IXGBE_LINKS_UP))
>> + goto dma_engine_disable;
>> +
>> + /* Determine our minimum delay interval. We will increase this
>> value
>> + * with each subsequent test. This way if the device returns
>> quickly
>> + * we should spend as little time as possible waiting, however as
>> + * the time increases we will wait for larger periods of time.
>> + *
>> + * The trick here is that we increase the interval using the
>> + * following pattern: 1x 3x 5x 7x 9x 11x 13x 15x 17x 19x. The
>> result
>> + * of that wait is that it totals up to 100x whatever interval we
>> + * choose. Since our minimum wait is 100us we can just divide the
>> + * total timeout by 100 to get our minimum delay interval.
>> + */
>> + delay_interval = ixgbe_get_completion_timeout(adapter) / 100;
>> +
>> + wait_loop = IXGBE_MAX_RX_DESC_POLL;
>> + wait_delay = delay_interval;
>> +
>> + while (wait_loop--) {
>> + usleep_range(wait_delay, wait_delay + 10);
>> + wait_delay += delay_interval * 2;
>> + txdctl = 0;
>> +
>> + /* OR together the reading of all the active TXDCTL
>> registers,
>> + * and then test the result. We need the disable to
>> complete
>> + * before we start freeing the memory and invalidating the
>> + * DMA mappings.
>> + */
>> + for (i = 0; i < adapter->num_tx_queues; i++) {
>> + struct ixgbe_ring *ring = adapter->tx_ring[i];
>> + u8 reg_idx = ring->reg_idx;
>> +
>> + txdctl |= IXGBE_READ_REG(hw,
>> IXGBE_TXDCTL(reg_idx));
>> + }
>> + for (i = 0; i < adapter->num_xdp_queues; i++) {
>> + struct ixgbe_ring *ring = adapter->xdp_ring[i];
>> + u8 reg_idx = ring->reg_idx;
>> +
>> + txdctl |= IXGBE_READ_REG(hw,
>> IXGBE_TXDCTL(reg_idx));
>> + }
>> +
>> + if (!(txdctl & IXGBE_TXDCTL_ENABLE))
>> + goto dma_engine_disable;
>> + }
>> +
>> + e_err(drv,
>> + "TXDCTL.ENABLE for one or more queues not cleared within the
>> polling period\n");
>> +
>> +dma_engine_disable:
>> + /* Disable the Tx DMA engine on 82599 and later MAC */
>> + switch (hw->mac.type) {
>> + case ixgbe_mac_82599EB:
>> + case ixgbe_mac_X540:
>> + case ixgbe_mac_X550:
>> + case ixgbe_mac_X550EM_x:
>> + case ixgbe_mac_x550em_a:
>> + IXGBE_WRITE_REG(hw, IXGBE_DMATXCTL,
>> + (IXGBE_READ_REG(hw, IXGBE_DMATXCTL) &
>> + ~IXGBE_DMATXCTL_TE));
>> + /* fall through */
>> + default:
>> + break;
>> + }
>
>
> Picky bike-shed thoughts: I realize you're just moving the previously
> existing code, but with the comment "... and later MAC" I would think the
> translation to code puts all the later MACs into the default and have the
> WRITE_REG() as the default action. This would make it default to the
> correct action for any new MACs if someone forgot to fix up this part of the
> code.
>
> switch (hw->mac.type) {
> case ixgbe_mac_82598EB:
> break;
>
> case ixgbe_mac_82599EB:
> case ixgbe_mac_X540:
> case ixgbe_mac_X550:
> case ixgbe_mac_X550EM_x:
> case ixgbe_mac_x550em_a:
> default:
> IXGBE_WRITE_REG(hw, IXGBE_DMATXCTL,
> (IXGBE_READ_REG(hw, IXGBE_DMATXCTL) &
> ~IXGBE_DMATXCTL_TE));
> break;
> }
>
> Or even simpler,
>
> if (hw->mac.type != ixgbe_mac_82598EB)
> IXGBE_WRITE_REG(hw, IXGBE_DMATXCTL,
> (IXGBE_READ_REG(hw, IXGBE_DMATXCTL) &
> ~IXGBE_DMATXCTL_TE));
>
> Okay, I'll stop now.
>
> Cheers,
> sln
Yeah, for now I will probably leave the code as is, but this is
something that could be updated int he future. Either that or you are
always free to submit a patch.. :-)
- Alex
^ permalink raw reply
* Applied "regmap: sccb: fix typo and sort headers alphabetically" to the regmap tree
From: Mark Brown @ 2018-07-23 17:10 UTC (permalink / raw)
To: Akinobu Mita; +Cc: Wolfram Sang, Mark Brown, linux-kernel
The patch
regmap: sccb: fix typo and sort headers alphabetically
has been applied to the regmap tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From 75eb3a67a29e9f87c07c8bd184a7ed4274a58ef0 Mon Sep 17 00:00:00 2001
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Mon, 23 Jul 2018 00:45:46 +0900
Subject: [PATCH] regmap: sccb: fix typo and sort headers alphabetically
Fix typos 's/wit/with/' in the comments and sort headers alphabetically
in order to avoid duplicate includes in future.
Fixes: bcf7eac3d97f ("regmap: add SCCB support")
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/base/regmap/regmap-sccb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/base/regmap/regmap-sccb.c b/drivers/base/regmap/regmap-sccb.c
index b6eb876ea819..597042e2d009 100644
--- a/drivers/base/regmap/regmap-sccb.c
+++ b/drivers/base/regmap/regmap-sccb.c
@@ -1,9 +1,9 @@
// SPDX-License-Identifier: GPL-2.0
// Register map access API - SCCB support
-#include <linux/regmap.h>
#include <linux/i2c.h>
#include <linux/module.h>
+#include <linux/regmap.h>
#include "internal.h"
@@ -29,7 +29,7 @@ static bool sccb_is_available(struct i2c_adapter *adap)
/**
* regmap_sccb_read - Read data from SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
* @reg: Register to be read from
* @val: Pointer to store read value
*
@@ -65,7 +65,7 @@ static int regmap_sccb_read(void *context, unsigned int reg, unsigned int *val)
/**
* regmap_sccb_write - Write data to SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
* @reg: Register to write to
* @val: Value to be written
*
--
2.18.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.