* [PATCH] mtd: mtd-abi: Don't use C++ comments
From: Nathan Chancellor @ 2019-06-20 15:55 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Marek Vasut, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra
Cc: linux-mtd, linux-kernel, clang-built-linux, Nathan Chancellor
When compiled standalone after commit b91976b7c0e3 ("kbuild:
compile-test UAPI headers to ensure they are self-contained"),
a warning about the C++ comments appears:
In file included from usr/include/mtd/mtd-user.hdrtest.c:1:
In file included from ./usr/include/mtd/mtd-user.h:25:
./usr/include/mtd/mtd-abi.h:116:28: warning: // comments are not
allowed in this language [-Wcomment]
#define MTD_NANDECC_OFF 0 // Switch off ECC (Not recommended)
^
1 warning generated.
Replace them with standard C comments so this warning no longer occurs.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
include/uapi/mtd/mtd-abi.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
index aff5b5e59845..3fe9237f723a 100644
--- a/include/uapi/mtd/mtd-abi.h
+++ b/include/uapi/mtd/mtd-abi.h
@@ -113,11 +113,11 @@ struct mtd_write_req {
#define MTD_CAP_NVRAM (MTD_WRITEABLE | MTD_BIT_WRITEABLE | MTD_NO_ERASE)
/* Obsolete ECC byte placement modes (used with obsolete MEMGETOOBSEL) */
-#define MTD_NANDECC_OFF 0 // Switch off ECC (Not recommended)
-#define MTD_NANDECC_PLACE 1 // Use the given placement in the structure (YAFFS1 legacy mode)
-#define MTD_NANDECC_AUTOPLACE 2 // Use the default placement scheme
-#define MTD_NANDECC_PLACEONLY 3 // Use the given placement in the structure (Do not store ecc result on read)
-#define MTD_NANDECC_AUTOPL_USR 4 // Use the given autoplacement scheme rather than using the default
+#define MTD_NANDECC_OFF 0 /* Switch off ECC (Not recommended) */
+#define MTD_NANDECC_PLACE 1 /* Use the given placement in the structure (YAFFS1 legacy mode) */
+#define MTD_NANDECC_AUTOPLACE 2 /* Use the default placement scheme */
+#define MTD_NANDECC_PLACEONLY 3 /* Use the given placement in the structure (Do not store ecc result on read) */
+#define MTD_NANDECC_AUTOPL_USR 4 /* Use the given autoplacement scheme rather than using the default */
/* OTP mode selection */
#define MTD_OTP_OFF 0
--
2.22.0
^ permalink raw reply related
* Re: [Qemu-devel] [RFC] nvme: how to support multiple namespaces
From: Laszlo Ersek @ 2019-06-20 15:37 UTC (permalink / raw)
To: qemu-devel, Keith Busch, Kevin Wolf, Max Reitz, qemu-block,
Markus Armbruster
In-Reply-To: <20190617081205.GA26990@apples.localdomain>
On 06/17/19 10:12, Klaus Birkelund wrote:
> Hi all,
>
> I'm thinking about how to support multiple namespaces in the NVMe
> device. My first idea was to add a "namespaces" property array to the
> device that references blockdevs, but as Laszlo writes below, this might
> not be the best idea. It also makes it troublesome to add per-namespace
> parameters (which is something I will be required to do for other
> reasons). Some of you might remember my first attempt at this that
> included adding a new block driver (derived from raw) that could be
> given certain parameters that would then be stored in the image. But I
> understand that this is a no-go, and I can see why.
>
> I guess the optimal way would be such that the parameters was something
> like:
>
> -blockdev raw,node-name=blk_ns1,file.driver=file,file.filename=blk_ns1.img
> -blockdev raw,node-name=blk_ns2,file.driver=file,file.filename=blk_ns2.img
> -device nvme-ns,drive=blk_ns1,ns-specific-options (nsfeat,mc,dlfeat)...
> -device nvme-ns,drive=blk_ns2,...
> -device nvme,...
>
> My question is how to state the parent/child relationship between the
> nvme and nvme-ns devices. I've been looking at how ide and virtio does
> this, and maybe a "bus" is the right way to go?
I've added Markus to the address list, because of this question. No
other (new) comments from me on the thread starter at this time, just
keeping the full context.
Thanks
Laszlo
>
> Can anyone give any advice as to how to proceed? I have a functioning
> patch that adds multiple namespaces, but it uses the "namespaces" array
> method and I don't think that is the right approach.
>
> I've copied my initial discussion with Laszlo below.
>
>
> Cheers,
> Klaus
>
>
> On Wed, Jun 05, 2019 at 07:09:43PM +0200, Laszlo Ersek wrote:
>> On 06/05/19 15:44, Klaus Birkelund wrote:
>>> On Tue, Jun 04, 2019 at 06:52:38PM +0200, Laszlo Ersek wrote:
>>>> Hi Klaus,
>>>>
>>>> On 06/04/19 14:59, Klaus Birkelund wrote:
>>>>> Hi Laszlo,
>>>>>
>>>>> I'm implementing multiple namespace support for the NVMe device in QEMU
>>>>> and I'm not sure how to handle the bootindex property.
>>>>>
>>>>> Your commit message from a907ec52cc1a provides great insight, but do you
>>>>> have any recommendations to how the bootindex property should be
>>>>> handled?
>>>>>
>>>>> Multiple namespaces work by having multiple -blockdevs and then using
>>>>> the property array functionality to reference a list of blockdevs from
>>>>> the nvme device:
>>>>>
>>>>> -device nvme,serial=<serial>,len-namespaces=1,namespace[0]=<drive_id>
>>>>>
>>>>> A bootindex property would be global to the device. Should it just
>>>>> always default to the first namespace? I'm really unsure about how the
>>>>> firmware handles it.
>>>>>
>>>>> Hope you can shed some light on this.
>>>>
>>>> this is getting quite seriously into QOM and QEMU options, so I
>>>> definitely suggest to take this to the list, because I'm not an expert
>>>> in all that, at all :)
>>>>
>>>> Based on a re-reading of the commit (which I have *completely* forgotten
>>>> about by now!), and based on your description, my opinion is that
>>>> introducing the "namespace" property to the "nvme" device as an array is
>>>> a bad fit. Because, as you say, a single device may only take a single
>>>> bootindex property. If it suffices to designate at most one namespace
>>>> for booting purposes, then I *guess* an extra property can be
>>>> introduced, to state *which* namespace the bootindex property should
>>>> apply to (and the rest of the namespaces will be ignored for that
>>>> purpose). However, if it's necessary to add at least two namespaces to
>>>> the boot order, then the namespaces will have to be split to distinct
>>>> "-device" options.
>>>>
>>>> My impression is that the "namespace" property isn't upstream yet; i.e.
>>>> it is your work in progress. As a "QOM noob" I would suggest introducing
>>>> a new device model, called "nvme-namespace". This could have its own
>>>> "bootindex" property. On the "nvme" device model's level, the currently
>>>> existing "bootindex" property would become mutually exclusive with the
>>>> "nvme" device having "nvme-namespace" child devices. The parent-child
>>>> relationship could be expressed from either direction, i.e. either the
>>>> "nvme" parent device could reference the children with the "namespace"
>>>> array property (it wouldn't refer to <drive_id>s but to the IDs of
>>>> "nvme-namespace" devices), or the "nvme-namespace" devices could
>>>> reference the parent "nvme" device via a "bus" property or similar.
>>>>
>>>> The idea is that "bootindex" would have to exist at the nvme-namespace
>>>> device model's level, and a parent ("bus") device would have to enforce
>>>> various properties, such as no namespace ID duplication and so on.
>>>>
>>>> I suggest that, if/when you respond to this email, keep all context, and
>>>> CC the qemu-devel list at once. (I could have done that myself right
>>>> now, but didn't want to, without your permission.)
>>>>
>>>
>>> Hi Laszlo,
>>>
>>> Thank you very much for the feedback!
>>>
>>> I have a big patch series for the nvme device which the multiple
>>> namespace patch builds on. I'll post the big series tomorrow I hope.
>>> Then I'll post the multiple namespaces patch as an RFC and include our
>>> discussion here.
>>>
>>> I hadn't thought about introducing a separate device model for the
>>> namespace. It's way beyond my QOM knowledge, so yeah, hopefully someone
>>> on the list have some opinions on this.
>>>
>>>
>>> Thanks again!
>>
>> My pleasure! I'll attempt to follow the discussion (from a safe distance
>> :) ) because I'm curious about the proper device model hierarchy here.
>>
>> Regarding OVMF, as long as your QEMU work keeps the *structure* of the
>> OpenFirmware device paths intact (and you just compose the NSID and
>> EUI-64 values dynamically, in the trailing "unit address" part), OVMF
>> should need no change.
>>
>> Thanks!
>> Laszlo
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v5 1/2] i2c: Move bitbang_i2c.h to include/hw/i2c/
From: Philippe Mathieu-Daudé @ 2019-06-20 15:46 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel; +Cc: Corey Minyard, Gerd Hoffmann
In-Reply-To: <5d1fe4db846ab9be4b77ddb0d43cc74cd200a003.1561028123.git.balaton@eik.bme.hu>
On 6/20/19 12:55 PM, BALATON Zoltan wrote:
> The bitbang i2c implementation is also useful for other device models
> such as DDC in display controllers. Move the header to include/hw/i2c/
> to allow it to be used from other device models and adjust users of
> this include. This also reverts commit 2b4c1125ac which is no longer
> needed.
>
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> hw/i2c/bitbang_i2c.c | 2 +-
> hw/i2c/ppc4xx_i2c.c | 1 -
> hw/i2c/versatile_i2c.c | 2 +-
> {hw => include/hw}/i2c/bitbang_i2c.h | 2 ++
> include/hw/i2c/i2c.h | 2 --
> include/hw/i2c/ppc4xx_i2c.h | 2 +-
> 6 files changed, 5 insertions(+), 6 deletions(-)
> rename {hw => include/hw}/i2c/bitbang_i2c.h (80%)
>
> diff --git a/hw/i2c/bitbang_i2c.c b/hw/i2c/bitbang_i2c.c
> index 5dfc72d9d7..3cb0509b02 100644
> --- a/hw/i2c/bitbang_i2c.c
> +++ b/hw/i2c/bitbang_i2c.c
> @@ -12,7 +12,7 @@
>
> #include "qemu/osdep.h"
> #include "hw/hw.h"
> -#include "bitbang_i2c.h"
> +#include "hw/i2c/bitbang_i2c.h"
> #include "hw/sysbus.h"
> #include "qemu/module.h"
>
> diff --git a/hw/i2c/ppc4xx_i2c.c b/hw/i2c/ppc4xx_i2c.c
> index d606d3dbeb..5fb4f86c38 100644
> --- a/hw/i2c/ppc4xx_i2c.c
> +++ b/hw/i2c/ppc4xx_i2c.c
> @@ -30,7 +30,6 @@
> #include "cpu.h"
> #include "hw/hw.h"
> #include "hw/i2c/ppc4xx_i2c.h"
> -#include "bitbang_i2c.h"
>
> #define PPC4xx_I2C_MEM_SIZE 18
>
> diff --git a/hw/i2c/versatile_i2c.c b/hw/i2c/versatile_i2c.c
> index e07be9890c..24b6e36b6d 100644
> --- a/hw/i2c/versatile_i2c.c
> +++ b/hw/i2c/versatile_i2c.c
> @@ -23,7 +23,7 @@
>
> #include "qemu/osdep.h"
> #include "hw/sysbus.h"
> -#include "bitbang_i2c.h"
> +#include "hw/i2c/bitbang_i2c.h"
> #include "qemu/log.h"
> #include "qemu/module.h"
>
> diff --git a/hw/i2c/bitbang_i2c.h b/include/hw/i2c/bitbang_i2c.h
> similarity index 80%
> rename from hw/i2c/bitbang_i2c.h
> rename to include/hw/i2c/bitbang_i2c.h
> index 9443021710..3a7126d5de 100644
> --- a/hw/i2c/bitbang_i2c.h
> +++ b/include/hw/i2c/bitbang_i2c.h
> @@ -3,6 +3,8 @@
>
> #include "hw/i2c/i2c.h"
>
> +typedef struct bitbang_i2c_interface bitbang_i2c_interface;
> +
> #define BITBANG_I2C_SDA 0
> #define BITBANG_I2C_SCL 1
>
> diff --git a/include/hw/i2c/i2c.h b/include/hw/i2c/i2c.h
> index 8e236f7bb4..75c5bd638b 100644
> --- a/include/hw/i2c/i2c.h
> +++ b/include/hw/i2c/i2c.h
> @@ -81,8 +81,6 @@ uint8_t i2c_recv(I2CBus *bus);
>
> DeviceState *i2c_create_slave(I2CBus *bus, const char *name, uint8_t addr);
>
> -typedef struct bitbang_i2c_interface bitbang_i2c_interface;
> -
> /* lm832x.c */
> void lm832x_key_event(DeviceState *dev, int key, int state);
>
> diff --git a/include/hw/i2c/ppc4xx_i2c.h b/include/hw/i2c/ppc4xx_i2c.h
> index aa2a2bf9de..8437bf070b 100644
> --- a/include/hw/i2c/ppc4xx_i2c.h
> +++ b/include/hw/i2c/ppc4xx_i2c.h
> @@ -28,7 +28,7 @@
> #define PPC4XX_I2C_H
>
> #include "hw/sysbus.h"
> -#include "hw/i2c/i2c.h"
> +#include "hw/i2c/bitbang_i2c.h"
>
> #define TYPE_PPC4xx_I2C "ppc4xx-i2c"
> #define PPC4xx_I2C(obj) OBJECT_CHECK(PPC4xxI2CState, (obj), TYPE_PPC4xx_I2C)
>
^ permalink raw reply
* Re: [PATCH v2 3/3] media: stm32-dcmi: add support of several sub-devices
From: Sakari Ailus @ 2019-06-20 15:54 UTC (permalink / raw)
To: Hugues Fruchet
Cc: Yannick Fertre, Alexandre Torgue, Mickael GUENE, linux-kernel,
Philippe CORNU, Hans Verkuil, Benjamin Gaignard,
Mauro Carvalho Chehab, linux-stm32, linux-arm-kernel, linux-media
In-Reply-To: <1560242912-17138-4-git-send-email-hugues.fruchet@st.com>
Hi Hugues,
Thank you for the update.
On Tue, Jun 11, 2019 at 10:48:32AM +0200, Hugues Fruchet wrote:
> Add support of several sub-devices within pipeline instead
> of a single one.
> This allows to support a CSI-2 camera sensor connected
> through a CSI-2 to parallel bridge.
>
> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
> ---
> drivers/media/platform/stm32/stm32-dcmi.c | 207 +++++++++++++++++++++++++++---
> 1 file changed, 189 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index 3a69783..144912f 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -173,6 +173,7 @@ struct stm32_dcmi {
>
> struct media_device mdev;
> struct media_pad vid_cap_pad;
> + struct media_pipeline pipeline;
> };
>
> static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
> @@ -584,6 +585,135 @@ static void dcmi_buf_queue(struct vb2_buffer *vb)
> spin_unlock_irq(&dcmi->irqlock);
> }
>
> +static struct media_entity *dcmi_find_sensor(struct stm32_dcmi *dcmi)
You generally should be only concerned with the next entity connected to the
one you're in control of, not the rest of the pipeline.
> +{
> + struct media_entity *entity = &dcmi->vdev->entity;
> + struct v4l2_subdev *subdev;
> + struct media_pad *pad;
> +
> + /* Walk searching for entity having no sink */
> + while (1) {
> + pad = &entity->pads[0];
> +
> + subdev = media_entity_to_v4l2_subdev(entity);
> +
> + if (!(pad->flags & MEDIA_PAD_FL_SINK))
> + break;
> +
> + pad = media_entity_remote_pad(pad);
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> + break;
> +
> + entity = pad->entity;
> + }
> +
> + return entity;
> +}
> +
> +static int dcmi_pipeline_s_fmt(struct stm32_dcmi *dcmi,
> + struct v4l2_subdev_pad_config *pad_cfg,
> + struct v4l2_subdev_format *format)
> +{
> + struct media_entity *entity = &dcmi->sensor->entity;
> + struct v4l2_subdev *subdev;
> + struct media_pad *sink_pad = NULL;
> + struct media_pad *src_pad = NULL;
> + struct media_pad *pad = NULL;
> + struct v4l2_subdev_format fmt = *format;
> + bool found = false;
> + int ret;
> +
> + /*
> + * Starting from sensor subdevice, walk within
> + * pipeline and set format on each subdevice
> + */
> + while (1) {
> + unsigned int i;
> +
> + /* Search if current entity has a source pad */
> + for (i = 0; i < entity->num_pads; i++) {
> + pad = &entity->pads[i];
> + if (pad->flags & MEDIA_PAD_FL_SOURCE) {
> + src_pad = pad;
> + found = true;
> + break;
> + }
> + }
> + if (!found)
> + break;
> +
> + subdev = media_entity_to_v4l2_subdev(entity);
> +
> + /* Propagate format on sink pad if any, otherwise source pad */
> + if (sink_pad)
> + pad = sink_pad;
> +
> + dev_dbg(dcmi->dev, "%s[%d] pad format set to 0x%x %ux%u\n",
> + subdev->name, pad->index, format->format.code,
> + format->format.width, format->format.height);
> +
> + fmt.pad = pad->index;
> + ret = v4l2_subdev_call(subdev, pad, set_fmt, pad_cfg, &fmt);
Generally speaking, on MC-centric devices, the user space needs to
configure the pipeline. The driver's responsibility is to validate it
(through the link_validate media entity and subdev pad ops). I.e. set_fmt
is only used through the subdev nodes.
> + if (ret < 0)
> + return ret;
> +
> + /* Walk to next entity */
> + sink_pad = media_entity_remote_pad(src_pad);
> + if (!sink_pad || !is_media_entity_v4l2_subdev(sink_pad->entity))
> + break;
> +
> + entity = sink_pad->entity;
> + }
> + *format = fmt;
> +
> + return 0;
> +}
> +
> +static int dcmi_pipeline_s_stream(struct stm32_dcmi *dcmi, int state)
> +{
> + struct media_entity *entity = &dcmi->vdev->entity;
> + struct v4l2_subdev *subdev;
> + struct media_pad *pad;
> + int ret;
> +
> + /* Start/stop all entities within pipeline */
> + while (1) {
> + pad = &entity->pads[0];
> + if (!(pad->flags & MEDIA_PAD_FL_SINK))
> + break;
> +
> + pad = media_entity_remote_pad(pad);
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> + break;
> +
> + entity = pad->entity;
> + subdev = media_entity_to_v4l2_subdev(entity);
> +
> + ret = v4l2_subdev_call(subdev, video, s_stream, state);
Please only call this on the next upstream sub-device. See e.g. the
ipu3-cio2 or omap3isp driver for an example.
> + if (ret < 0 && ret != -ENOIOCTLCMD) {
> + dev_err(dcmi->dev, "%s: %s failed to %s streaming (%d)\n",
> + __func__, subdev->name,
> + state ? "start" : "stop", ret);
> + return ret;
> + }
> +
> + dev_dbg(dcmi->dev, "%s is %s\n",
> + subdev->name, state ? "started" : "stopped");
> + }
> +
> + return 0;
> +}
> +
> +static int dcmi_pipeline_start(struct stm32_dcmi *dcmi)
> +{
> + return dcmi_pipeline_s_stream(dcmi, 1);
> +}
> +
> +static void dcmi_pipeline_stop(struct stm32_dcmi *dcmi)
> +{
> + dcmi_pipeline_s_stream(dcmi, 0);
> +}
> +
> static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
> {
> struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
> @@ -598,14 +728,17 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
> goto err_release_buffers;
> }
>
> - /* Enable stream on the sub device */
> - ret = v4l2_subdev_call(dcmi->sensor, video, s_stream, 1);
> - if (ret && ret != -ENOIOCTLCMD) {
> - dev_err(dcmi->dev, "%s: Failed to start streaming, subdev streamon error",
> - __func__);
> + ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
> + if (ret < 0) {
> + dev_err(dcmi->dev, "%s: Failed to start streaming, media pipeline start error (%d)\n",
> + __func__, ret);
> goto err_pm_put;
> }
>
> + ret = dcmi_pipeline_start(dcmi);
> + if (ret)
> + goto err_media_pipeline_stop;
> +
> spin_lock_irq(&dcmi->irqlock);
>
> /* Set bus width */
> @@ -677,7 +810,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
> if (ret) {
> dev_err(dcmi->dev, "%s: Start streaming failed, cannot start capture\n",
> __func__);
> - goto err_subdev_streamoff;
> + goto err_pipeline_stop;
> }
>
> /* Enable interruptions */
> @@ -688,8 +821,11 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
>
> return 0;
>
> -err_subdev_streamoff:
> - v4l2_subdev_call(dcmi->sensor, video, s_stream, 0);
> +err_pipeline_stop:
> + dcmi_pipeline_stop(dcmi);
> +
> +err_media_pipeline_stop:
> + media_pipeline_stop(&dcmi->vdev->entity);
>
> err_pm_put:
> pm_runtime_put(dcmi->dev);
> @@ -714,13 +850,10 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
> {
> struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
> struct dcmi_buf *buf, *node;
> - int ret;
>
> - /* Disable stream on the sub device */
> - ret = v4l2_subdev_call(dcmi->sensor, video, s_stream, 0);
> - if (ret && ret != -ENOIOCTLCMD)
> - dev_err(dcmi->dev, "%s: Failed to stop streaming, subdev streamoff error (%d)\n",
> - __func__, ret);
> + dcmi_pipeline_stop(dcmi);
> +
> + media_pipeline_stop(&dcmi->vdev->entity);
>
> spin_lock_irq(&dcmi->irqlock);
>
> @@ -938,8 +1071,7 @@ static int dcmi_set_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f)
> mf->width = sd_framesize.width;
> mf->height = sd_framesize.height;
>
> - ret = v4l2_subdev_call(dcmi->sensor, pad,
> - set_fmt, NULL, &format);
> + ret = dcmi_pipeline_s_fmt(dcmi, NULL, &format);
> if (ret < 0)
> return ret;
>
> @@ -1530,7 +1662,19 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
> struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
> int ret;
>
> + /*
> + * Now that the graph is complete,
> + * we search for the camera sensor subdevice
> + * in order to expose it through V4L2 interface
> + */
> + dcmi->sensor = media_entity_to_v4l2_subdev(dcmi_find_sensor(dcmi));
> + if (!dcmi->sensor) {
> + dev_err(dcmi->dev, "No camera sensor subdevice found\n");
> + return -ENODEV;
> + }
> +
> dcmi->vdev->ctrl_handler = dcmi->sensor->ctrl_handler;
> +
> ret = dcmi_formats_init(dcmi);
> if (ret) {
> dev_err(dcmi->dev, "No supported mediabus format found\n");
> @@ -1574,12 +1718,30 @@ static int dcmi_graph_notify_bound(struct v4l2_async_notifier *notifier,
> struct v4l2_async_subdev *asd)
> {
> struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
> + unsigned int ret;
> + int src_pad;
>
> dev_dbg(dcmi->dev, "Subdev %s bound\n", subdev->name);
>
> - dcmi->sensor = subdev;
> + /*
> + * Link this sub-device to DCMI, it could be
> + * a parallel camera sensor or a bridge
> + */
> + src_pad = media_entity_get_fwnode_pad(&subdev->entity,
> + subdev->fwnode,
> + MEDIA_PAD_FL_SOURCE);
> +
> + ret = media_create_pad_link(&subdev->entity, src_pad,
> + &dcmi->vdev->entity, 0,
> + MEDIA_LNK_FL_IMMUTABLE |
> + MEDIA_LNK_FL_ENABLED);
> + if (ret)
> + dev_err(dcmi->dev, "Failed to create media pad link with subdev %s\n",
> + subdev->name);
> + else
> + dev_dbg(dcmi->dev, "DCMI is now linked to %s\n", subdev->name);
>
> - return 0;
> + return ret;
> }
>
> static const struct v4l2_async_notifier_operations dcmi_graph_notify_ops = {
> @@ -1639,6 +1801,15 @@ static int dcmi_graph_init(struct stm32_dcmi *dcmi)
> return ret;
> }
>
> + /* Register all the subdev nodes */
> + ret = v4l2_device_register_subdev_nodes(&dcmi->v4l2_dev);
> + if (ret) {
> + dev_err(dcmi->dev, "Failed to register subdev nodes\n");
> + v4l2_async_notifier_unregister(&dcmi->notifier);
> + of_node_put(dcmi->entity.node);
> + return ret;
> + }
> +
> return 0;
> }
>
--
regards,
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/3] media: stm32-dcmi: add support of several sub-devices
From: Sakari Ailus @ 2019-06-20 15:54 UTC (permalink / raw)
To: Hugues Fruchet
Cc: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
linux-media, linux-arm-kernel, linux-kernel, linux-stm32,
Benjamin Gaignard, Yannick Fertre, Philippe CORNU, Mickael GUENE
In-Reply-To: <1560242912-17138-4-git-send-email-hugues.fruchet@st.com>
Hi Hugues,
Thank you for the update.
On Tue, Jun 11, 2019 at 10:48:32AM +0200, Hugues Fruchet wrote:
> Add support of several sub-devices within pipeline instead
> of a single one.
> This allows to support a CSI-2 camera sensor connected
> through a CSI-2 to parallel bridge.
>
> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
> ---
> drivers/media/platform/stm32/stm32-dcmi.c | 207 +++++++++++++++++++++++++++---
> 1 file changed, 189 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index 3a69783..144912f 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -173,6 +173,7 @@ struct stm32_dcmi {
>
> struct media_device mdev;
> struct media_pad vid_cap_pad;
> + struct media_pipeline pipeline;
> };
>
> static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
> @@ -584,6 +585,135 @@ static void dcmi_buf_queue(struct vb2_buffer *vb)
> spin_unlock_irq(&dcmi->irqlock);
> }
>
> +static struct media_entity *dcmi_find_sensor(struct stm32_dcmi *dcmi)
You generally should be only concerned with the next entity connected to the
one you're in control of, not the rest of the pipeline.
> +{
> + struct media_entity *entity = &dcmi->vdev->entity;
> + struct v4l2_subdev *subdev;
> + struct media_pad *pad;
> +
> + /* Walk searching for entity having no sink */
> + while (1) {
> + pad = &entity->pads[0];
> +
> + subdev = media_entity_to_v4l2_subdev(entity);
> +
> + if (!(pad->flags & MEDIA_PAD_FL_SINK))
> + break;
> +
> + pad = media_entity_remote_pad(pad);
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> + break;
> +
> + entity = pad->entity;
> + }
> +
> + return entity;
> +}
> +
> +static int dcmi_pipeline_s_fmt(struct stm32_dcmi *dcmi,
> + struct v4l2_subdev_pad_config *pad_cfg,
> + struct v4l2_subdev_format *format)
> +{
> + struct media_entity *entity = &dcmi->sensor->entity;
> + struct v4l2_subdev *subdev;
> + struct media_pad *sink_pad = NULL;
> + struct media_pad *src_pad = NULL;
> + struct media_pad *pad = NULL;
> + struct v4l2_subdev_format fmt = *format;
> + bool found = false;
> + int ret;
> +
> + /*
> + * Starting from sensor subdevice, walk within
> + * pipeline and set format on each subdevice
> + */
> + while (1) {
> + unsigned int i;
> +
> + /* Search if current entity has a source pad */
> + for (i = 0; i < entity->num_pads; i++) {
> + pad = &entity->pads[i];
> + if (pad->flags & MEDIA_PAD_FL_SOURCE) {
> + src_pad = pad;
> + found = true;
> + break;
> + }
> + }
> + if (!found)
> + break;
> +
> + subdev = media_entity_to_v4l2_subdev(entity);
> +
> + /* Propagate format on sink pad if any, otherwise source pad */
> + if (sink_pad)
> + pad = sink_pad;
> +
> + dev_dbg(dcmi->dev, "%s[%d] pad format set to 0x%x %ux%u\n",
> + subdev->name, pad->index, format->format.code,
> + format->format.width, format->format.height);
> +
> + fmt.pad = pad->index;
> + ret = v4l2_subdev_call(subdev, pad, set_fmt, pad_cfg, &fmt);
Generally speaking, on MC-centric devices, the user space needs to
configure the pipeline. The driver's responsibility is to validate it
(through the link_validate media entity and subdev pad ops). I.e. set_fmt
is only used through the subdev nodes.
> + if (ret < 0)
> + return ret;
> +
> + /* Walk to next entity */
> + sink_pad = media_entity_remote_pad(src_pad);
> + if (!sink_pad || !is_media_entity_v4l2_subdev(sink_pad->entity))
> + break;
> +
> + entity = sink_pad->entity;
> + }
> + *format = fmt;
> +
> + return 0;
> +}
> +
> +static int dcmi_pipeline_s_stream(struct stm32_dcmi *dcmi, int state)
> +{
> + struct media_entity *entity = &dcmi->vdev->entity;
> + struct v4l2_subdev *subdev;
> + struct media_pad *pad;
> + int ret;
> +
> + /* Start/stop all entities within pipeline */
> + while (1) {
> + pad = &entity->pads[0];
> + if (!(pad->flags & MEDIA_PAD_FL_SINK))
> + break;
> +
> + pad = media_entity_remote_pad(pad);
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
> + break;
> +
> + entity = pad->entity;
> + subdev = media_entity_to_v4l2_subdev(entity);
> +
> + ret = v4l2_subdev_call(subdev, video, s_stream, state);
Please only call this on the next upstream sub-device. See e.g. the
ipu3-cio2 or omap3isp driver for an example.
> + if (ret < 0 && ret != -ENOIOCTLCMD) {
> + dev_err(dcmi->dev, "%s: %s failed to %s streaming (%d)\n",
> + __func__, subdev->name,
> + state ? "start" : "stop", ret);
> + return ret;
> + }
> +
> + dev_dbg(dcmi->dev, "%s is %s\n",
> + subdev->name, state ? "started" : "stopped");
> + }
> +
> + return 0;
> +}
> +
> +static int dcmi_pipeline_start(struct stm32_dcmi *dcmi)
> +{
> + return dcmi_pipeline_s_stream(dcmi, 1);
> +}
> +
> +static void dcmi_pipeline_stop(struct stm32_dcmi *dcmi)
> +{
> + dcmi_pipeline_s_stream(dcmi, 0);
> +}
> +
> static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
> {
> struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
> @@ -598,14 +728,17 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
> goto err_release_buffers;
> }
>
> - /* Enable stream on the sub device */
> - ret = v4l2_subdev_call(dcmi->sensor, video, s_stream, 1);
> - if (ret && ret != -ENOIOCTLCMD) {
> - dev_err(dcmi->dev, "%s: Failed to start streaming, subdev streamon error",
> - __func__);
> + ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
> + if (ret < 0) {
> + dev_err(dcmi->dev, "%s: Failed to start streaming, media pipeline start error (%d)\n",
> + __func__, ret);
> goto err_pm_put;
> }
>
> + ret = dcmi_pipeline_start(dcmi);
> + if (ret)
> + goto err_media_pipeline_stop;
> +
> spin_lock_irq(&dcmi->irqlock);
>
> /* Set bus width */
> @@ -677,7 +810,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
> if (ret) {
> dev_err(dcmi->dev, "%s: Start streaming failed, cannot start capture\n",
> __func__);
> - goto err_subdev_streamoff;
> + goto err_pipeline_stop;
> }
>
> /* Enable interruptions */
> @@ -688,8 +821,11 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
>
> return 0;
>
> -err_subdev_streamoff:
> - v4l2_subdev_call(dcmi->sensor, video, s_stream, 0);
> +err_pipeline_stop:
> + dcmi_pipeline_stop(dcmi);
> +
> +err_media_pipeline_stop:
> + media_pipeline_stop(&dcmi->vdev->entity);
>
> err_pm_put:
> pm_runtime_put(dcmi->dev);
> @@ -714,13 +850,10 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
> {
> struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
> struct dcmi_buf *buf, *node;
> - int ret;
>
> - /* Disable stream on the sub device */
> - ret = v4l2_subdev_call(dcmi->sensor, video, s_stream, 0);
> - if (ret && ret != -ENOIOCTLCMD)
> - dev_err(dcmi->dev, "%s: Failed to stop streaming, subdev streamoff error (%d)\n",
> - __func__, ret);
> + dcmi_pipeline_stop(dcmi);
> +
> + media_pipeline_stop(&dcmi->vdev->entity);
>
> spin_lock_irq(&dcmi->irqlock);
>
> @@ -938,8 +1071,7 @@ static int dcmi_set_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f)
> mf->width = sd_framesize.width;
> mf->height = sd_framesize.height;
>
> - ret = v4l2_subdev_call(dcmi->sensor, pad,
> - set_fmt, NULL, &format);
> + ret = dcmi_pipeline_s_fmt(dcmi, NULL, &format);
> if (ret < 0)
> return ret;
>
> @@ -1530,7 +1662,19 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
> struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
> int ret;
>
> + /*
> + * Now that the graph is complete,
> + * we search for the camera sensor subdevice
> + * in order to expose it through V4L2 interface
> + */
> + dcmi->sensor = media_entity_to_v4l2_subdev(dcmi_find_sensor(dcmi));
> + if (!dcmi->sensor) {
> + dev_err(dcmi->dev, "No camera sensor subdevice found\n");
> + return -ENODEV;
> + }
> +
> dcmi->vdev->ctrl_handler = dcmi->sensor->ctrl_handler;
> +
> ret = dcmi_formats_init(dcmi);
> if (ret) {
> dev_err(dcmi->dev, "No supported mediabus format found\n");
> @@ -1574,12 +1718,30 @@ static int dcmi_graph_notify_bound(struct v4l2_async_notifier *notifier,
> struct v4l2_async_subdev *asd)
> {
> struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
> + unsigned int ret;
> + int src_pad;
>
> dev_dbg(dcmi->dev, "Subdev %s bound\n", subdev->name);
>
> - dcmi->sensor = subdev;
> + /*
> + * Link this sub-device to DCMI, it could be
> + * a parallel camera sensor or a bridge
> + */
> + src_pad = media_entity_get_fwnode_pad(&subdev->entity,
> + subdev->fwnode,
> + MEDIA_PAD_FL_SOURCE);
> +
> + ret = media_create_pad_link(&subdev->entity, src_pad,
> + &dcmi->vdev->entity, 0,
> + MEDIA_LNK_FL_IMMUTABLE |
> + MEDIA_LNK_FL_ENABLED);
> + if (ret)
> + dev_err(dcmi->dev, "Failed to create media pad link with subdev %s\n",
> + subdev->name);
> + else
> + dev_dbg(dcmi->dev, "DCMI is now linked to %s\n", subdev->name);
>
> - return 0;
> + return ret;
> }
>
> static const struct v4l2_async_notifier_operations dcmi_graph_notify_ops = {
> @@ -1639,6 +1801,15 @@ static int dcmi_graph_init(struct stm32_dcmi *dcmi)
> return ret;
> }
>
> + /* Register all the subdev nodes */
> + ret = v4l2_device_register_subdev_nodes(&dcmi->v4l2_dev);
> + if (ret) {
> + dev_err(dcmi->dev, "Failed to register subdev nodes\n");
> + v4l2_async_notifier_unregister(&dcmi->notifier);
> + of_node_put(dcmi->entity.node);
> + return ret;
> + }
> +
> return 0;
> }
>
--
regards,
Sakari Ailus
sakari.ailus@linux.intel.com
^ permalink raw reply
* [PATCH] dmaengine: tegra210-adma: remove PM_CLK dependency
From: Sameer Pujar @ 2019-06-20 15:54 UTC (permalink / raw)
To: vkoul, dan.j.williams
Cc: thierry.reding, jonathanh, ldewangan, dmaengine, linux-tegra,
linux-kernel, Sameer Pujar
Tegra ADMA does not use pm-clk interface now and hence the dependency
is removed from Kconfig.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 703275c..ba660e2 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -584,7 +584,7 @@ config TEGRA20_APB_DMA
config TEGRA210_ADMA
tristate "NVIDIA Tegra210 ADMA support"
- depends on (ARCH_TEGRA_210_SOC || COMPILE_TEST) && PM_CLK
+ depends on (ARCH_TEGRA_210_SOC || COMPILE_TEST)
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
help
--
2.7.4
^ permalink raw reply related
* [PATCH] dmaengine: tegra210-adma: remove PM_CLK dependency
From: Sameer Pujar @ 2019-06-20 15:54 UTC (permalink / raw)
To: vkoul, dan.j.williams
Cc: thierry.reding, jonathanh, ldewangan, dmaengine, linux-tegra,
linux-kernel, Sameer Pujar
Tegra ADMA does not use pm-clk interface now and hence the dependency
is removed from Kconfig.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 703275c..ba660e2 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -584,7 +584,7 @@ config TEGRA20_APB_DMA
config TEGRA210_ADMA
tristate "NVIDIA Tegra210 ADMA support"
- depends on (ARCH_TEGRA_210_SOC || COMPILE_TEST) && PM_CLK
+ depends on (ARCH_TEGRA_210_SOC || COMPILE_TEST)
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
help
--
2.7.4
^ permalink raw reply related
* Re: [linux-sunxi] [PATCH v7 0/6] Add support for Orange Pi 3
From: Jernej Škrabec @ 2019-06-20 15:53 UTC (permalink / raw)
To: linux-sunxi, megous
Cc: Mark Rutland, Jose Abreu, Alexandre Torgue, devicetree,
Maxime Ripard, netdev, linux-kernel, dri-devel, linux-stm32,
David Airlie, Chen-Yu Tsai, Rob Herring, linux-arm-kernel,
Daniel Vetter, Giuseppe Cavallaro, David S. Miller,
Maxime Coquelin
In-Reply-To: <20190620134748.17866-1-megous@megous.com>
Hi!
Dne četrtek, 20. junij 2019 ob 15:47:42 CEST je megous via linux-sunxi
napisal(a):
> From: Ondrej Jirman <megous@megous.com>
>
> This series implements support for Xunlong Orange Pi 3 board.
>
> - ethernet support (patches 1-3)
Correct me if I'm wrong, but patches 1-2 aren't strictly necessary for
OrangePi 3, right? H6 DTSI already has emac node with dual compatible (H6 and
A64) and since OrangePi 3 uses gigabit ethernet, quirk introduced by patches
1-2 are not needed.
However, it is nice to have this 100 Mbit fix, because most STB DTS will need
it.
Best regards,
Jernej
> - HDMI support (patches 4-6)
>
> For some people, ethernet doesn't work after reboot (but works on cold
> boot), when the stmmac driver is built into the kernel. It works when
> the driver is built as a module. It's either some timing issue, or power
> supply issue or a combination of both. Module build induces a power
> cycling of the phy.
>
> I encourage people with this issue, to build the driver into the kernel,
> and try to alter the reset timings for the phy in DTS or
> startup-delay-us and report the findings.
>
>
> Please take a look.
>
> thank you and regards,
> Ondrej Jirman
>
>
> Changes in v7:
> - dropped stored reference to connector_pdev as suggested by Jernej
> - added forgotten dt-bindings reviewed-by tag
>
> Changes in v6:
> - added dt-bindings reviewed-by tag
> - fix wording in stmmac commit (as suggested by Sergei)
>
> Changes in v5:
> - dropped already applied patches (pinctrl patches, mmc1 pinconf patch)
> - rename GMAC-3V3 -> GMAC-3V to match the schematic (Jagan)
> - changed hdmi-connector's ddc-supply property to ddc-en-gpios
> (Rob Herring)
>
> Changes in v4:
> - fix checkpatch warnings/style issues
> - use enum in struct sunxi_desc_function for io_bias_cfg_variant
> - collected acked-by's
> - fix compile error in drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c:156
> caused by missing conversion from has_io_bias_cfg struct member
> (I've kept the acked-by, because it's a trivial change, but feel free
> to object.) (reported by Martin A. on github)
> I did not have A80 pinctrl enabled for some reason, so I did not catch
> this sooner.
> - dropped brcm firmware patch (was already applied)
> - dropped the wifi dts patch (will re-send after H6 RTC gets merged,
> along with bluetooth support, in a separate series)
>
> Changes in v3:
> - dropped already applied patches
> - changed pinctrl I/O bias selection constants to enum and renamed
> - added /omit-if-no-ref/ to mmc1_pins
> - made mmc1_pins default pinconf for mmc1 in H6 dtsi
> - move ddc-supply to HDMI connector node, updated patch descriptions,
> changed dt-bindings docs
>
> Changes in v2:
> - added dt-bindings documentation for the board's compatible string
> (suggested by Clement)
> - addressed checkpatch warnings and code formatting issues (on Maxime's
> suggestions)
> - stmmac: dropped useless parenthesis, reworded description of the patch
> (suggested by Sergei)
> - drop useles dev_info() about the selected io bias voltage
> - docummented io voltage bias selection variant macros
> - wifi: marked WiFi DTS patch and realted mmc1_pins as "DO NOT MERGE",
> because wifi depends on H6 RTC support that's not merged yet (suggested
> by Clement)
> - added missing signed-of-bys
> - changed &usb2otg dr_mode to otg, and added a note about VBUS
> - improved wording of HDMI driver's DDC power supply patch
>
> Icenowy Zheng (2):
> net: stmmac: sun8i: add support for Allwinner H6 EMAC
> net: stmmac: sun8i: force select external PHY when no internal one
>
> Ondrej Jirman (4):
> arm64: dts: allwinner: orange-pi-3: Enable ethernet
> dt-bindings: display: hdmi-connector: Support DDC bus enable
> drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
> arm64: dts: allwinner: orange-pi-3: Enable HDMI output
>
> .../display/connector/hdmi-connector.txt | 1 +
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 70 +++++++++++++++++++
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 54 ++++++++++++--
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +
> .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 21 ++++++
> 5 files changed, 144 insertions(+), 4 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v7 0/6] Add support for Orange Pi 3
From: Jernej Škrabec @ 2019-06-20 15:53 UTC (permalink / raw)
To: linux-sunxi, megous
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie,
Daniel Vetter, Mark Rutland, Giuseppe Cavallaro, Alexandre Torgue,
Jose Abreu, David S. Miller, Maxime Coquelin, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, netdev, linux-stm32
In-Reply-To: <20190620134748.17866-1-megous@megous.com>
Hi!
Dne četrtek, 20. junij 2019 ob 15:47:42 CEST je megous via linux-sunxi
napisal(a):
> From: Ondrej Jirman <megous@megous.com>
>
> This series implements support for Xunlong Orange Pi 3 board.
>
> - ethernet support (patches 1-3)
Correct me if I'm wrong, but patches 1-2 aren't strictly necessary for
OrangePi 3, right? H6 DTSI already has emac node with dual compatible (H6 and
A64) and since OrangePi 3 uses gigabit ethernet, quirk introduced by patches
1-2 are not needed.
However, it is nice to have this 100 Mbit fix, because most STB DTS will need
it.
Best regards,
Jernej
> - HDMI support (patches 4-6)
>
> For some people, ethernet doesn't work after reboot (but works on cold
> boot), when the stmmac driver is built into the kernel. It works when
> the driver is built as a module. It's either some timing issue, or power
> supply issue or a combination of both. Module build induces a power
> cycling of the phy.
>
> I encourage people with this issue, to build the driver into the kernel,
> and try to alter the reset timings for the phy in DTS or
> startup-delay-us and report the findings.
>
>
> Please take a look.
>
> thank you and regards,
> Ondrej Jirman
>
>
> Changes in v7:
> - dropped stored reference to connector_pdev as suggested by Jernej
> - added forgotten dt-bindings reviewed-by tag
>
> Changes in v6:
> - added dt-bindings reviewed-by tag
> - fix wording in stmmac commit (as suggested by Sergei)
>
> Changes in v5:
> - dropped already applied patches (pinctrl patches, mmc1 pinconf patch)
> - rename GMAC-3V3 -> GMAC-3V to match the schematic (Jagan)
> - changed hdmi-connector's ddc-supply property to ddc-en-gpios
> (Rob Herring)
>
> Changes in v4:
> - fix checkpatch warnings/style issues
> - use enum in struct sunxi_desc_function for io_bias_cfg_variant
> - collected acked-by's
> - fix compile error in drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c:156
> caused by missing conversion from has_io_bias_cfg struct member
> (I've kept the acked-by, because it's a trivial change, but feel free
> to object.) (reported by Martin A. on github)
> I did not have A80 pinctrl enabled for some reason, so I did not catch
> this sooner.
> - dropped brcm firmware patch (was already applied)
> - dropped the wifi dts patch (will re-send after H6 RTC gets merged,
> along with bluetooth support, in a separate series)
>
> Changes in v3:
> - dropped already applied patches
> - changed pinctrl I/O bias selection constants to enum and renamed
> - added /omit-if-no-ref/ to mmc1_pins
> - made mmc1_pins default pinconf for mmc1 in H6 dtsi
> - move ddc-supply to HDMI connector node, updated patch descriptions,
> changed dt-bindings docs
>
> Changes in v2:
> - added dt-bindings documentation for the board's compatible string
> (suggested by Clement)
> - addressed checkpatch warnings and code formatting issues (on Maxime's
> suggestions)
> - stmmac: dropped useless parenthesis, reworded description of the patch
> (suggested by Sergei)
> - drop useles dev_info() about the selected io bias voltage
> - docummented io voltage bias selection variant macros
> - wifi: marked WiFi DTS patch and realted mmc1_pins as "DO NOT MERGE",
> because wifi depends on H6 RTC support that's not merged yet (suggested
> by Clement)
> - added missing signed-of-bys
> - changed &usb2otg dr_mode to otg, and added a note about VBUS
> - improved wording of HDMI driver's DDC power supply patch
>
> Icenowy Zheng (2):
> net: stmmac: sun8i: add support for Allwinner H6 EMAC
> net: stmmac: sun8i: force select external PHY when no internal one
>
> Ondrej Jirman (4):
> arm64: dts: allwinner: orange-pi-3: Enable ethernet
> dt-bindings: display: hdmi-connector: Support DDC bus enable
> drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
> arm64: dts: allwinner: orange-pi-3: Enable HDMI output
>
> .../display/connector/hdmi-connector.txt | 1 +
> .../dts/allwinner/sun50i-h6-orangepi-3.dts | 70 +++++++++++++++++++
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 54 ++++++++++++--
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +
> .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 21 ++++++
> 5 files changed, 144 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: network unstable on odroid-c1/meson8b.
From: Heiner Kallweit @ 2019-06-20 15:53 UTC (permalink / raw)
To: Aymeric; +Cc: Martin Blumenstingl, netdev, linux-amlogic
In-Reply-To: <d2e298040f4887c547da11178f9ea64f@aplu.fr>
On 20.06.2019 09:55, Aymeric wrote:
> Hi,
> On 2019-06-20 00:14, Heiner Kallweit wrote:
>> On 19.06.2019 22:18, Aymeric wrote:
>>> Hello all,
>>>
>
>> Kernel 3.10 didn't have a dedicated RTL8211F PHY driver yet, therefore
>> I assume the genphy driver was used. Do you have a line with
>> "attached PHY driver" in dmesg output of the vendor kernel?
>
> No.
> Here is the full output of the dmesg from vendor kernel [¹].
>
> I've also noticed something strange, it might be linked, but mac address of the board is set to a random value when using mainline kernel and I've to set it manually but not when using vendor kernel.
>
>>
>> The dedicated PHY driver takes care of the tx delay, if the genphy
>> driver is used we have to rely on what uboot configured.
>> But if we indeed had an issue with a misconfigured delay, I think
>> the connection shouldn't be fine with just another link partner.
>> Just to have it tested you could make rtl8211f_config_init() in
>> drivers/net/phy/realtek.c a no-op (in current kernels).
>>
>
> I'm not an expert here, just adding a "return 0;" here[²] would be enough?
>
>> And you could compare at least the basic PHY registers 0x00 - 0x30
>> with both kernel versions, e.g. with phytool.
>>
>
> They are not the same but I don't know what I'm looking for, so for kernel 3.10 [³] and for kernel 5.1.12 [⁴].
>
> Aymeric
>
> [¹]: https://paste.aplu.fr/?38ef95b44ebdbfc3#G666/YbhgU+O+tdC/2HaimUCigm8ZTB44qvQip/HJ5A=
> [²]: https://github.com/torvalds/linux/blob/241e39004581475b2802cd63c111fec43bb0123e/drivers/net/phy/realtek.c#L164
> [³]: https://paste.aplu.fr/?2dde1c32d5c68f4c#6xIa8MjTm6jpI6citEJAqFTLMMHDjFZRet/M00/EwjU=
> [⁴]: https://paste.aplu.fr/?32130e9bcb05dde7#N/xdnvb5GklcJtiOxMpTCm+9gsUliRwH8X3dcwSV+ng=
>
The vendor kernel has some, but not really much magic:
https://github.com/hardkernel/linux/blob/odroidc-3.10.y/drivers/amlogic/ethernet/phy/am_rtl8211f.c
The write to RTL8211F_PHYCR2 is overwritten later, therefore we don't have to consider it.
The following should make the current Realtek PHY driver behave like in the vendor driver.
Could you test it?
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index a669945eb..f300b1cc9 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -163,6 +163,10 @@ static int rtl8211f_config_init(struct phy_device *phydev)
{
u16 val;
+ phy_write_paged(phydev, 0x0a43, 0x19, 0x0803);
+ genphy_soft_reset(phydev);
+ return 0;
+
/* enable TX-delay for rgmii-{id,txid}, and disable it for rgmii and
* rgmii-rxid. The RX-delay can be enabled by the external RXDLY pin.
*/
--
2.22.0
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply related
* Re: network unstable on odroid-c1/meson8b.
From: Heiner Kallweit @ 2019-06-20 15:53 UTC (permalink / raw)
To: Aymeric; +Cc: netdev, linux-amlogic, Martin Blumenstingl
In-Reply-To: <d2e298040f4887c547da11178f9ea64f@aplu.fr>
On 20.06.2019 09:55, Aymeric wrote:
> Hi,
> On 2019-06-20 00:14, Heiner Kallweit wrote:
>> On 19.06.2019 22:18, Aymeric wrote:
>>> Hello all,
>>>
>
>> Kernel 3.10 didn't have a dedicated RTL8211F PHY driver yet, therefore
>> I assume the genphy driver was used. Do you have a line with
>> "attached PHY driver" in dmesg output of the vendor kernel?
>
> No.
> Here is the full output of the dmesg from vendor kernel [¹].
>
> I've also noticed something strange, it might be linked, but mac address of the board is set to a random value when using mainline kernel and I've to set it manually but not when using vendor kernel.
>
>>
>> The dedicated PHY driver takes care of the tx delay, if the genphy
>> driver is used we have to rely on what uboot configured.
>> But if we indeed had an issue with a misconfigured delay, I think
>> the connection shouldn't be fine with just another link partner.
>> Just to have it tested you could make rtl8211f_config_init() in
>> drivers/net/phy/realtek.c a no-op (in current kernels).
>>
>
> I'm not an expert here, just adding a "return 0;" here[²] would be enough?
>
>> And you could compare at least the basic PHY registers 0x00 - 0x30
>> with both kernel versions, e.g. with phytool.
>>
>
> They are not the same but I don't know what I'm looking for, so for kernel 3.10 [³] and for kernel 5.1.12 [⁴].
>
> Aymeric
>
> [¹]: https://paste.aplu.fr/?38ef95b44ebdbfc3#G666/YbhgU+O+tdC/2HaimUCigm8ZTB44qvQip/HJ5A=
> [²]: https://github.com/torvalds/linux/blob/241e39004581475b2802cd63c111fec43bb0123e/drivers/net/phy/realtek.c#L164
> [³]: https://paste.aplu.fr/?2dde1c32d5c68f4c#6xIa8MjTm6jpI6citEJAqFTLMMHDjFZRet/M00/EwjU=
> [⁴]: https://paste.aplu.fr/?32130e9bcb05dde7#N/xdnvb5GklcJtiOxMpTCm+9gsUliRwH8X3dcwSV+ng=
>
The vendor kernel has some, but not really much magic:
https://github.com/hardkernel/linux/blob/odroidc-3.10.y/drivers/amlogic/ethernet/phy/am_rtl8211f.c
The write to RTL8211F_PHYCR2 is overwritten later, therefore we don't have to consider it.
The following should make the current Realtek PHY driver behave like in the vendor driver.
Could you test it?
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index a669945eb..f300b1cc9 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -163,6 +163,10 @@ static int rtl8211f_config_init(struct phy_device *phydev)
{
u16 val;
+ phy_write_paged(phydev, 0x0a43, 0x19, 0x0803);
+ genphy_soft_reset(phydev);
+ return 0;
+
/* enable TX-delay for rgmii-{id,txid}, and disable it for rgmii and
* rgmii-rxid. The RX-delay can be enabled by the external RXDLY pin.
*/
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] kbuild: Remove unnecessary -Wno-unused-value
From: Masahiro Yamada @ 2019-06-20 15:52 UTC (permalink / raw)
To: Nathan Huckleberry
Cc: Michal Marek, Linux Kbuild mailing list,
Linux Kernel Mailing List, Nick Desaulniers, clang-built-linux
In-Reply-To: <20190617172829.164520-1-nhuck@google.com>
On Tue, Jun 18, 2019 at 2:28 AM Nathan Huckleberry <nhuck@google.com> wrote:
>
> This flag turns off several other warnings that would
> be useful. Most notably -warn_unused_result is disabled.
> All of the following warnings are currently disabled:
>
> UnusedValue
> |-UnusedComparison
> |-warn_unused_comparison
> |-UnusedResult
> |-warn_unused_result
> |-UnevaluatedExpression
> |-PotentiallyEvaluatedExpression
> |-warn_side_effects_typeid
> |-warn_side_effects_unevaluated_context
> |-warn_unused_expr
> |-warn_unused_voidptr
> |-warn_unused_container_subscript_expr
> |-warn_unused_call
>
> With this flag removed there are ~10 warnings.
> Patches have been submitted for each of these warnings.
>
> Reported-by: Nick Desaulniers <ndesaulniers@google.com>
> Cc: clang-built-linux@googlegroups.com
> Link: https://github.com/ClangBuiltLinux/linux/issues/520
> Signed-off-by: Nathan Huckleberry <nhuck@google.com>
> ---
Applied to linux-kbuild.
Thanks!
> scripts/Makefile.extrawarn | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> index 3ab8d1a303cd..b293246e48fe 100644
> --- a/scripts/Makefile.extrawarn
> +++ b/scripts/Makefile.extrawarn
> @@ -68,7 +68,6 @@ else
>
> ifdef CONFIG_CC_IS_CLANG
> KBUILD_CFLAGS += -Wno-initializer-overrides
> -KBUILD_CFLAGS += -Wno-unused-value
> KBUILD_CFLAGS += -Wno-format
> KBUILD_CFLAGS += -Wno-sign-compare
> KBUILD_CFLAGS += -Wno-format-zero-length
> --
> 2.22.0.410.gd8fdbe21b5-goog
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 05/20] hw/i386/pc: Add documentation to the e820_*() functions
From: Michael S. Tsirkin @ 2019-06-20 15:36 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Yang Zhong, Eduardo Habkost, kvm, Marcelo Tosatti, qemu-devel,
Rob Bradford, Paolo Bonzini, Samuel Ortiz, Richard Henderson
In-Reply-To: <20190613143446.23937-6-philmd@redhat.com>
On Thu, Jun 13, 2019 at 04:34:31PM +0200, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
> include/hw/i386/pc.h | 37 +++++++++++++++++++++++++++++++++++--
> 1 file changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 7c07185dd5..fc66b61ff8 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -293,9 +293,42 @@ typedef enum {
> E820_UNUSABLE = 5
> } E820Type;
>
> -ssize_t e820_add_entry(uint64_t, uint64_t, uint32_t);
> +/**
> + * e820_add_entry: Add an #e820_entry to the @e820_table.
> + *
> + * Returns the number of entries of the e820_table on success,
> + * or a negative errno otherwise.
> + *
> + * @address: The base address of the structure which the BIOS is to fill in.
> + * @length: The length in bytes of the structure passed to the BIOS.
> + * @type: The #E820Type of the address range.
> + */
> +ssize_t e820_add_entry(uint64_t address, uint64_t length, E820Type type);
> +
> +/**
> + * e820_get_num_entries: The number of entries of the @e820_table.
> + *
> + * Returns the number of entries of the e820_table.
> + */
> size_t e820_get_num_entries(void);
> -bool e820_get_entry(unsigned int, uint32_t, uint64_t *, uint64_t *);
> +
> +/**
> + * e820_get_entry: Get the address/length of an #e820_entry.
> + *
> + * If the #e820_entry stored at @index is of #E820Type @type, fills @address
> + * and @length with the #e820_entry values and return @true.
> + * Return @false otherwise.
> + *
> + * @index: The index of the #e820_entry to get values.
> + * @type: The @E820Type of the address range expected.
> + * @address: Pointer to the base address of the #e820_entry structure to
> + * be filled.
> + * @length: Pointer to the length (in bytes) of the #e820_entry structure
> + * to be filled.
> + * @return: true if the entry was found, false otherwise.
I don't actually care whether it's @E820Type, #E820Type or just type,
we should be consistent. I also find this style of documentation
underwhelming. what is to be filled? length or the structure?
upper case after : also looks somewhat wrong.
Same applies to other comments too.
> + */
> +bool e820_get_entry(unsigned int index, E820Type type,
> + uint64_t *address, uint64_t *length);
>
> extern GlobalProperty pc_compat_4_0_1[];
> extern const size_t pc_compat_4_0_1_len;
> --
> 2.20.1
^ permalink raw reply
* [PATCH] bus: tegra-aconnect: remove PM_CLK dependency
From: Sameer Pujar @ 2019-06-20 15:51 UTC (permalink / raw)
To: thierry.reding, jonathanh; +Cc: linux-tegra, linux-kernel, Sameer Pujar
aconnect bus driver does not use pm-clk interface now and hence the
dependency is removed from Kconfig.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
---
drivers/bus/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 1851112..4587ef2 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -128,7 +128,6 @@ config TEGRA_ACONNECT
tristate "Tegra ACONNECT Bus Driver"
depends on ARCH_TEGRA_210_SOC
depends on OF && PM
- select PM_CLK
help
Driver for the Tegra ACONNECT bus which is used to interface with
the devices inside the Audio Processing Engine (APE) for Tegra210.
--
2.7.4
^ permalink raw reply related
* [PATCH] bus: tegra-aconnect: remove PM_CLK dependency
From: Sameer Pujar @ 2019-06-20 15:51 UTC (permalink / raw)
To: thierry.reding, jonathanh; +Cc: linux-tegra, linux-kernel, Sameer Pujar
aconnect bus driver does not use pm-clk interface now and hence the
dependency is removed from Kconfig.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
---
drivers/bus/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 1851112..4587ef2 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -128,7 +128,6 @@ config TEGRA_ACONNECT
tristate "Tegra ACONNECT Bus Driver"
depends on ARCH_TEGRA_210_SOC
depends on OF && PM
- select PM_CLK
help
Driver for the Tegra ACONNECT bus which is used to interface with
the devices inside the Audio Processing Engine (APE) for Tegra210.
--
2.7.4
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 04/12] hbitmap: Fix merge when b is empty, and result is not an alias of a
From: Max Reitz @ 2019-06-20 15:39 UTC (permalink / raw)
To: John Snow, qemu-devel, qemu-block
Cc: Kevin Wolf, Fam Zheng, vsementsov, Wen Congyang, Xie Changlong,
Markus Armbruster
In-Reply-To: <20190620010356.19164-5-jsnow@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1565 bytes --]
On 20.06.19 03:03, John Snow wrote:
> Nobody calls the function like this currently, but we neither prohibit
> or cope with this behavior. I decided to make the function cope with it.
>
> Signed-off-by: John Snow <jsnow@redhat.com>
> ---
> util/hbitmap.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/util/hbitmap.c b/util/hbitmap.c
> index 7905212a8b..45d1725daf 100644
> --- a/util/hbitmap.c
> +++ b/util/hbitmap.c
> @@ -781,8 +781,9 @@ bool hbitmap_can_merge(const HBitmap *a, const HBitmap *b)
> }
>
> /**
> - * Given HBitmaps A and B, let A := A (BITOR) B.
> - * Bitmap B will not be modified.
> + * Given HBitmaps A and B, let R := A (BITOR) B.
> + * Bitmaps A and B will not be modified,
> + * except when bitmap R is an alias of A or B.
> *
> * @return true if the merge was successful,
> * false if it was not attempted.
> @@ -797,7 +798,9 @@ bool hbitmap_merge(const HBitmap *a, const HBitmap *b, HBitmap *result)
> }
> assert(hbitmap_can_merge(b, result));
>
> - if (hbitmap_count(b) == 0) {
> + if ((!hbitmap_count(a) && result == b) ||
> + (!hbitmap_count(b) && result == a) ||
> + (!hbitmap_count(a) && !hbitmap_count(b))) {
> return true;
> }
The rest of this function completely overwrites the @result bitmap.
Therefor, @result does not need to be cleared when calling this function.
Therfore, hbitmap_merge(hbitmap_alloc(), hbitmap_alloc(), output) should
actually clear @output, I think.
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 02/20] hw/i386/pc: Use size_t type to hold/return a size of array
From: Michael S. Tsirkin @ 2019-06-20 15:28 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Yang Zhong, Eduardo Habkost, kvm, Marcelo Tosatti, Li Qiang,
qemu-devel, Rob Bradford, Paolo Bonzini, Samuel Ortiz,
Richard Henderson
In-Reply-To: <20190613143446.23937-3-philmd@redhat.com>
On Thu, Jun 13, 2019 at 04:34:28PM +0200, Philippe Mathieu-Daudé wrote:
> Reviewed-by: Li Qiang <liq3ea@gmail.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Motivation? do you expect more than 2^31 entries?
> ---
> hw/i386/pc.c | 4 ++--
> include/hw/i386/pc.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index bb3c74f4ca..ff0f6bbbb3 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -105,7 +105,7 @@ struct e820_table {
>
> static struct e820_table e820_reserve;
> static struct e820_entry *e820_table;
> -static unsigned e820_entries;
> +static size_t e820_entries;
> struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
>
> /* Physical Address of PVH entry point read from kernel ELF NOTE */
> @@ -901,7 +901,7 @@ int e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
> return e820_entries;
> }
>
> -int e820_get_num_entries(void)
> +size_t e820_get_num_entries(void)
> {
> return e820_entries;
> }
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 3b3a0d6e59..fc29893624 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -290,7 +290,7 @@ void pc_madt_cpu_entry(AcpiDeviceIf *adev, int uid,
> #define E820_UNUSABLE 5
>
> int e820_add_entry(uint64_t, uint64_t, uint32_t);
> -int e820_get_num_entries(void);
> +size_t e820_get_num_entries(void);
> bool e820_get_entry(unsigned int, uint32_t, uint64_t *, uint64_t *);
>
> extern GlobalProperty pc_compat_4_0_1[];
> --
> 2.20.1
^ permalink raw reply
* Re: [PATCH v2 2/2] ssh: Add interface ssh_search_dir
From: Dominick Grift @ 2019-06-20 15:50 UTC (permalink / raw)
To: Alexander Miroshnichenko; +Cc: selinux-refpolicy
In-Reply-To: <d15b7000-6866-46bb-8622-33c7cad5cc4b@millerson.name>
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]
On Thu, Jun 20, 2019 at 06:38:10PM +0300, Alexander Miroshnichenko wrote:
> On четверг, 20 июня 2019 г. 18:27:31 MSK, Dominick Grift wrote:
> > On Thu, Jun 20, 2019 at 06:05:57PM +0300, Alexander Miroshnichenko wrote:
> > > On четверг, 20 июня 2019 г. 17:50:11 MSK, Dominick Grift wrote: ...
> >
> > Yes this sucks. I would probably do the following instead:
> >
> > 1. echo "ignoredirs=/var/lib/gitolite" >> /etc/selinux/semanage.conf
> > 2. semodule -B && restorecon -RvF /var/lib/gitolite
> > 3. gitosis_read_lib_files(sshd_t)
>
> I can't use sshd_t in another policy without require statement.
> Or I need to add gitosis_read_lib_files(sshd_t) to ssh.te policy file.
> All 3 steps are ugly comparing with new ssh_search_dir() interface.
> Why such restrictions where caller must be the source for interface? It is
> not flexible.
You would need to add the gitosis_read_var_lib_files(sshd_t) to ssh.te yes.
I agree that this is ugly but the alternative is even more ugly, and I will say that this is just what I would do (you might want to wait for maintainer's advice instead of taking my advice)
This is one of those scenario's that are the exception rather than the rule. All options are bad.
The "restriction" is actually an unwritten rule as I cannot find any references to it in https://github.com/SELinuxProject/refpolicy/wiki/StyleGuide so you might be able to get away with it.
>
> >
> > Dont bother with labeling /var/lib/gitolite/.ssh differently
> >
> > > ...
> >
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply
* [Xen-devel] [PATCH] xen/arm: optee: fix compilation with GCC 4.8
From: Volodymyr Babchuk @ 2019-06-20 15:50 UTC (permalink / raw)
To: Stefano Stabellini, Julien Grall
Cc: xen-devel@lists.xenproject.org, Volodymyr Babchuk,
Stefano Stabellini
GCC 4.8 is unable to see that variables guest_pg, guest_data and
xen_data will be always initialized before access, so we need to
initialize them earlier.
Suggested-by: Stefano Stabellini <stefanos@xilinx.com>
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
---
xen/arch/arm/tee/optee.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c
index 14381d6b2d..5526875e6f 100644
--- a/xen/arch/arm/tee/optee.c
+++ b/xen/arch/arm/tee/optee.c
@@ -717,6 +717,19 @@ static int translate_noncontig(struct optee_domain *ctx,
gfn = gaddr_to_gfn(param->u.tmem.buf_ptr &
~(OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1));
+ /*
+ * We are initializing guest_pg, guest_data and xen_data with NULL
+ * to make GCC 4.8 happy, as it can't infer that those variables
+ * will be initialized with correct values in the loop below.
+ *
+ * This silences old GCC, but can lead to NULL dereference, in
+ * case of programmer's mistake. To minimize chance of this, we
+ * are initializing those variables there, instead of doing this
+ * at beginning of the function.
+ */
+ guest_pg = NULL;
+ xen_data = NULL;
+ guest_data = NULL;
while ( pg_count )
{
struct page_info *page;
--
2.21.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* Re: [PATCH net-next] netfilter: ipv6: Fix build error without CONFIG_IPV6
From: Pablo Neira Ayuso @ 2019-06-20 15:50 UTC (permalink / raw)
To: Yuehaibing
Cc: kadlec, fw, davem, rdunlap, linux-kernel, coreteam,
netfilter-devel, netdev
In-Reply-To: <d2eba9e4-34be-f9bb-f0fd-024fe81d2b02@huawei.com>
On Thu, Jun 20, 2019 at 11:26:01PM +0800, Yuehaibing wrote:
> Friendly ping...
>
> On 2019/6/12 16:47, YueHaibing wrote:
> > If CONFIG_IPV6 is not set, building fails:
> >
> > net/bridge/netfilter/nf_conntrack_bridge.o: In function `nf_ct_bridge_pre':
> > nf_conntrack_bridge.c:(.text+0x41c): undefined symbol `nf_ct_frag6_gather'
> > net/bridge/netfilter/nf_conntrack_bridge.o: In function `nf_ct_bridge_post':
> > nf_conntrack_bridge.c:(.text+0x820): undefined symbol `br_ip6_fragment'
Is this one enough to fix this problem?
https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git/commit/?id=16e6427c88c5b7e7b6612f6c286d5f71d659e5be
Thanks.
> > Reported-by: Hulk Robot <hulkci@huawei.com>
> > Reported-by: Randy Dunlap <rdunlap@infradead.org>
> > Fixes: c9bb6165a16e ("netfilter: nf_conntrack_bridge: fix CONFIG_IPV6=y")
> > Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> > ---
> > include/linux/netfilter_ipv6.h | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/netfilter_ipv6.h b/include/linux/netfilter_ipv6.h
> > index 3a3dc4b..0e1febc 100644
> > --- a/include/linux/netfilter_ipv6.h
> > +++ b/include/linux/netfilter_ipv6.h
> > @@ -108,8 +108,11 @@ static inline int nf_ipv6_br_defrag(struct net *net, struct sk_buff *skb,
> > return 1;
> >
> > return v6_ops->br_defrag(net, skb, user);
> > -#else
> > +#endif
> > +#if IS_BUILTIN(CONFIG_IPV6)
> > return nf_ct_frag6_gather(net, skb, user);
> > +#else
> > + return 1;
> > #endif
> > }
> >
> > @@ -133,8 +136,11 @@ static inline int nf_br_ip6_fragment(struct net *net, struct sock *sk,
> > return 1;
> >
> > return v6_ops->br_fragment(net, sk, skb, data, output);
> > -#else
> > +#endif
> > +#if IS_BUILTIN(CONFIG_IPV6)
> > return br_ip6_fragment(net, sk, skb, data, output);
> > +#else
> > + return 1;
> > #endif
> > }
> >
> >
>
^ permalink raw reply
* Re: [PATCH] usb: core: devio: add ioctls for suspend and resume
From: Alan Stern @ 2019-06-20 15:49 UTC (permalink / raw)
To: Mayuresh Kulkarni; +Cc: Oliver Neukum, Greg KH, patches, linux-usb
In-Reply-To: <1561043507.20348.26.camel@opensource.cirrus.com>
On Thu, 20 Jun 2019, Mayuresh Kulkarni wrote:
> On Wed, 2019-06-19 at 10:40 -0400, Alan Stern wrote:
> > The only solution I can think of is for the userspace program to first
> > set the device's autosuspend delay to 0. Then whenever the
> > WAIT_FOR_RESUME ioctl returns -- even if it returns immediately -- the
> > program should assume the suspend is over or is not going to happen.
> > Then the program can run normally for a short while (10 seconds,
> > perhaps) before making another attempt to suspend.
> >
>
> Looks like usb_autosuspend_delay parameter is applicable to all USB
> devices. Also, since it is a module parameter, it might be tuned on a
> particular platform (e.g.: from init.<vendor>.rc on Android).
> So, I am not sure if it is good idea to rely on user-space to change it
> and restore it to original value when the USB device of interest is
> detached.
That's up to you. There are lots of different ways to set the
autosuspend delay. For example, you could create a udev rule that
would do it only for the devices your program handles.
> > The only change I would make to the patch posted earlier is to have
> > proc_wait_for_resume() call usb_autoresume_device() and set
> > ps->suspend_requested = false before returning.
> >
> > Mayuresh, how does that sound?
>
> With the code-changes you send me (in response to the
> patch), usb_autoresume_device() will be called when the waiter
> in proc_wait_for_resume() will return and send some message to "know"
> why resume happened.
>
> With above proposed change, proc_wait_for_resume() will return
> with usb_autoresume_device() and suspend_requested = false. So when the
> user-space will send some message to "know" resume reason, the checks in
> ioctl() handler will be skipped.
>
> (Apologies if above is obvious, but still wanted to comment so that we
> are on same page).
>
> With that said, I think there would be an issue with "host-wake" case as
> below - the sequence of operations are:
> - suspend ioctl called: assume actual bus suspend happens
> - wait-for-resume ioctl called
> - after a while user-space wants to send a message (due to end user
> interaction for example)
>
> Here the ioctl() will do usb_autoresume_device() since suspend_requested
> = true. This will end up calling usbfs_notify_resume() which will
> release waiter in proc_wait_for_resume(). And due to above proposed
> change, it will end up calling usb_autoresume_device() again.
>
> As a result, suspend will not happen for next suspend ioctl call.
Obviously the code would need to be more careful. It would call
usb_autoresume_device() only if ps->suspend_requested was true.
Alan Stern
> So, looks like the original proposed change seems better here. On the
> side note, I am still in process of verifying the code changes.
^ permalink raw reply
* Re: mmotm 2019-06-19-20-32 uploaded (drivers/base/memory.c)
From: Randy Dunlap @ 2019-06-20 15:48 UTC (permalink / raw)
To: akpm, broonie, linux-fsdevel, linux-kernel, linux-mm, linux-next,
mhocko, mm-commits, sfr, David Hildenbrand
In-Reply-To: <20190620033253.hao9i0PFT%akpm@linux-foundation.org>
On 6/19/19 8:32 PM, akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2019-06-19-20-32 has been uploaded to
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> more than once a week.
>
on i386 or x86_64:
../drivers/base/memory.c: In function 'find_memory_block':
../drivers/base/memory.c:621:43: error: 'hint' undeclared (first use in this function); did you mean 'uint'?
return find_memory_block_by_id(block_id, hint);
^~~~
--
~Randy
^ permalink raw reply
* [PATCH] perl: Improve ptest package reproducibility
From: Joshua Watt @ 2019-06-20 15:48 UTC (permalink / raw)
To: openembedded-core
Fixes a few reproducibility issues in the perl ptest package:
1) config.log has a lot of paths encoded in it. This file is
unnecessary for ptest, so it is omitted from the package
2) Makefile.config has a lot of paths encoded in it. This file should
be fixed up using the same rules as several other files that are in
the package
3) Paths in DEBUG_PREFIX_MAP are not being correctly removed from files
because DEBUG_PREFIX_MAP is now several command line arguments.
Instead of requiring an exact match for all arguments, remove any
matching argument.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
meta/recipes-devtools/perl/perl-ptest.inc | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/perl/perl-ptest.inc b/meta/recipes-devtools/perl/perl-ptest.inc
index 9dd9b7da57f..7152057762f 100644
--- a/meta/recipes-devtools/perl/perl-ptest.inc
+++ b/meta/recipes-devtools/perl/perl-ptest.inc
@@ -2,6 +2,9 @@ inherit ptest
SRC_URI += "file://run-ptest \
"
+
+DEBUG_PREFIX_MAP_REGEX = "${@'\\|'.join(d.getVar('DEBUG_PREFIX_MAP').split())}"
+
do_install_ptest () {
mkdir -p ${D}${PTEST_PATH}
sed -e "s:\/usr\/local:${bindir}:g" -i cpan/version/t/*
@@ -13,7 +16,7 @@ do_install_ptest () {
--exclude='win32/config.*' --exclude=plan9 --exclude=README.plan9 --exclude=perlplan9.pod --exclude=Configure \
--exclude=veryclean.sh --exclude=realclean.sh --exclude=getioctlsizes \
--exclude=dl_aix.xs --exclude=sdbm.3 --exclude='cflags.SH' --exclude=makefile.old \
- --exclude=miniperl --exclude=generate_uudmap --exclude=patches * | ( cd ${D}${PTEST_PATH} && tar -x )
+ --exclude=miniperl --exclude=generate_uudmap --exclude=patches --exclude='config.log' * | ( cd ${D}${PTEST_PATH} && tar -x )
ln -sf ${bindir}/perl ${D}${PTEST_PATH}/t/perl
@@ -21,12 +24,12 @@ do_install_ptest () {
find "${D}${PTEST_PATH}" \
\( -name '*.PL' -o -name 'myconfig' -o -name 'cflags' -o -name '*.pl' -o -name '*.sh' -o -name '*.pm' \
-o -name 'h2xs' -o -name 'h2ph' \
- -o -name '*.h' -o -name 'config.sh-*' -o -name 'pod2man' -o -name 'pod2text' \) \
+ -o -name '*.h' -o -name 'config.sh-*' -o -name 'pod2man' -o -name 'pod2text' -o -name 'Makefile.config' \) \
-type f -exec sed -i \
-e "s,${D},,g" \
-e "s,--sysroot=${STAGING_DIR_HOST},,g" \
-e "s,-isystem${STAGING_INCDIR} ,,g" \
- -e 's|${DEBUG_PREFIX_MAP}||g' \
+ -e 's^${DEBUG_PREFIX_MAP_REGEX}^^g' \
-e "s,${STAGING_BINDIR_NATIVE}/perl-native/,${bindir}/,g" \
-e "s,${STAGING_LIBDIR},${libdir},g" \
-e "s,${STAGING_BINDIR},${bindir},g" \
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] mm: memcg/slab: properly handle kmem_caches reparented to root_mem_cgroup
From: Shakeel Butt @ 2019-06-20 15:48 UTC (permalink / raw)
To: Roman Gushchin
Cc: Andrew Morton, Vladimir Davydov, Linux MM, LKML, Kernel Team,
Johannes Weiner, Waiman Long, Christoph Lameter, Michal Hocko,
David Rientjes, Joonsoo Kim, Pekka Enberg
In-Reply-To: <20190620015554.1888119-1-guro@fb.com>
On Wed, Jun 19, 2019 at 6:57 PM Roman Gushchin <guro@fb.com> wrote:
>
> As a result of reparenting a kmem_cache might belong to the root
> memory cgroup. It happens when a top-level memory cgroup is removed,
> and all associated kmem_caches are reparented to the root memory
> cgroup.
>
> The root memory cgroup is special, and requires a special handling.
> Let's make sure that we don't try to charge or uncharge it,
> and we handle system-wide vmstats exactly as for root kmem_caches.
>
> Note, that we still need to alter the kmem_cache reference counter,
> so that the kmem_cache can be released properly.
>
> The issue was discovered by running CRIU tests; the following warning
> did appear:
>
> [ 381.345960] WARNING: CPU: 0 PID: 11655 at mm/page_counter.c:62
> page_counter_cancel+0x26/0x30
> [ 381.345992] Modules linked in:
> [ 381.345998] CPU: 0 PID: 11655 Comm: kworker/0:8 Not tainted
> 5.2.0-rc5-next-20190618+ #1
> [ 381.346001] Hardware name: Google Google Compute Engine/Google
> Compute Engine, BIOS Google 01/01/2011
> [ 381.346010] Workqueue: memcg_kmem_cache kmemcg_workfn
> [ 381.346013] RIP: 0010:page_counter_cancel+0x26/0x30
> [ 381.346017] Code: 1f 44 00 00 0f 1f 44 00 00 48 89 f0 53 48 f7 d8
> f0 48 0f c1 07 48 29 f0 48 89 c3 48 89 c6 e8 61 ff ff ff 48 85 db 78
> 02 5b c3 <0f> 0b 5b c3 66 0f 1f 44 00 00 0f 1f 44 00 00 48 85 ff 74 41
> 41 55
> [ 381.346019] RSP: 0018:ffffb3b34319f990 EFLAGS: 00010086
> [ 381.346022] RAX: fffffffffffffffc RBX: fffffffffffffffc RCX: 0000000000000004
> [ 381.346024] RDX: 0000000000000000 RSI: fffffffffffffffc RDI: ffff9c2cd7165270
> [ 381.346026] RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000001
> [ 381.346028] R10: 00000000000000c8 R11: ffff9c2cd684e660 R12: 00000000fffffffc
> [ 381.346030] R13: 0000000000000002 R14: 0000000000000006 R15: ffff9c2c8ce1f200
> [ 381.346033] FS: 0000000000000000(0000) GS:ffff9c2cd8200000(0000)
> knlGS:0000000000000000
> [ 381.346039] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 381.346041] CR2: 00000000007be000 CR3: 00000001cdbfc005 CR4: 00000000001606f0
> [ 381.346043] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 381.346045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 381.346047] Call Trace:
> [ 381.346054] page_counter_uncharge+0x1d/0x30
> [ 381.346065] __memcg_kmem_uncharge_memcg+0x39/0x60
> [ 381.346071] __free_slab+0x34c/0x460
> [ 381.346079] deactivate_slab.isra.80+0x57d/0x6d0
> [ 381.346088] ? add_lock_to_list.isra.36+0x9c/0xf0
> [ 381.346095] ? __lock_acquire+0x252/0x1410
> [ 381.346106] ? cpumask_next_and+0x19/0x20
> [ 381.346110] ? slub_cpu_dead+0xd0/0xd0
> [ 381.346113] flush_cpu_slab+0x36/0x50
> [ 381.346117] ? slub_cpu_dead+0xd0/0xd0
> [ 381.346125] on_each_cpu_mask+0x51/0x70
> [ 381.346131] ? ksm_migrate_page+0x60/0x60
> [ 381.346134] on_each_cpu_cond_mask+0xab/0x100
> [ 381.346143] __kmem_cache_shrink+0x56/0x320
> [ 381.346150] ? ret_from_fork+0x3a/0x50
> [ 381.346157] ? unwind_next_frame+0x73/0x480
> [ 381.346176] ? __lock_acquire+0x252/0x1410
> [ 381.346188] ? kmemcg_workfn+0x21/0x50
> [ 381.346196] ? __mutex_lock+0x99/0x920
> [ 381.346199] ? kmemcg_workfn+0x21/0x50
> [ 381.346205] ? kmemcg_workfn+0x21/0x50
> [ 381.346216] __kmemcg_cache_deactivate_after_rcu+0xe/0x40
> [ 381.346220] kmemcg_cache_deactivate_after_rcu+0xe/0x20
> [ 381.346223] kmemcg_workfn+0x31/0x50
> [ 381.346230] process_one_work+0x23c/0x5e0
> [ 381.346241] worker_thread+0x3c/0x390
> [ 381.346248] ? process_one_work+0x5e0/0x5e0
> [ 381.346252] kthread+0x11d/0x140
> [ 381.346255] ? kthread_create_on_node+0x60/0x60
> [ 381.346261] ret_from_fork+0x3a/0x50
> [ 381.346275] irq event stamp: 10302
> [ 381.346278] hardirqs last enabled at (10301): [<ffffffffb2c1a0b9>]
> _raw_spin_unlock_irq+0x29/0x40
> [ 381.346282] hardirqs last disabled at (10302): [<ffffffffb2182289>]
> on_each_cpu_mask+0x49/0x70
> [ 381.346287] softirqs last enabled at (10262): [<ffffffffb2191f4a>]
> cgroup_idr_replace+0x3a/0x50
> [ 381.346290] softirqs last disabled at (10260): [<ffffffffb2191f2d>]
> cgroup_idr_replace+0x1d/0x50
> [ 381.346293] ---[ end trace b324ba73eb3659f0 ]---
>
> Reported-by: Andrei Vagin <avagin@gmail.com>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Shakeel Butt <shakeelb@google.com>
> Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
> Cc: Waiman Long <longman@redhat.com>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: Pekka Enberg <penberg@kernel.org>
> ---
> mm/slab.h | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/mm/slab.h b/mm/slab.h
> index a4c9b9d042de..c02e7f44268b 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -294,8 +294,12 @@ static __always_inline int memcg_charge_slab(struct page *page,
> memcg = parent_mem_cgroup(memcg);
> rcu_read_unlock();
>
> - if (unlikely(!memcg))
> + if (unlikely(!memcg || mem_cgroup_is_root(memcg))) {
> + mod_node_page_state(page_pgdat(page), cache_vmstat_idx(s),
> + (1 << order));
> + percpu_ref_get_many(&s->memcg_params.refcnt, 1 << order);
> return true;
Should the above be "return 0;" instead of true?
> + }
>
> ret = memcg_kmem_charge_memcg(page, gfp, order, memcg);
> if (ret)
> @@ -324,9 +328,14 @@ static __always_inline void memcg_uncharge_slab(struct page *page, int order,
>
> rcu_read_lock();
> memcg = READ_ONCE(s->memcg_params.memcg);
> - lruvec = mem_cgroup_lruvec(page_pgdat(page), memcg);
> - mod_lruvec_state(lruvec, cache_vmstat_idx(s), -(1 << order));
> - memcg_kmem_uncharge_memcg(page, order, memcg);
> + if (likely(!mem_cgroup_is_root(memcg))) {
> + lruvec = mem_cgroup_lruvec(page_pgdat(page), memcg);
> + mod_lruvec_state(lruvec, cache_vmstat_idx(s), -(1 << order));
> + memcg_kmem_uncharge_memcg(page, order, memcg);
> + } else {
> + mod_node_page_state(page_pgdat(page), cache_vmstat_idx(s),
> + -(1 << order));
> + }
> rcu_read_unlock();
>
> percpu_ref_put_many(&s->memcg_params.refcnt, 1 << order);
> --
> 2.21.0
>
^ permalink raw reply
* Re: [linux-sunxi] [PATCH v7 5/6] drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue
From: Jernej Škrabec @ 2019-06-20 15:47 UTC (permalink / raw)
To: linux-sunxi, megous
Cc: Mark Rutland, Jose Abreu, Alexandre Torgue, devicetree,
Maxime Ripard, netdev, linux-kernel, dri-devel, linux-stm32,
David Airlie, Chen-Yu Tsai, Rob Herring, linux-arm-kernel,
Daniel Vetter, Giuseppe Cavallaro, David S. Miller,
Maxime Coquelin
In-Reply-To: <20190620134748.17866-6-megous@megous.com>
Dne četrtek, 20. junij 2019 ob 15:47:47 CEST je megous via linux-sunxi
napisal(a):
> From: Ondrej Jirman <megous@megous.com>
>
> Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> for the DDC bus to be usable.
>
> Add support for hdmi-connector node's optional ddc-en-gpios property to
> support this use case.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Best regards,
Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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.