Hi Ohad,
> On Sun, Feb 10, 2013 at 1:39 PM, wrote:
> > From: Dmitry Tarnyagin
> >
> > Fixes coherent memory leakage, caused by non-deallocated
> > firmware image chunk.
>
> I'll just slightly edit the subject + commit log to indicate this fix
> is STE-specific.
Sure, no problem.
>
> > Signe
Hi Rusty,
> From: Rusty Russell [mailto:ru...@rustcorp.com.au]
> sjur.brandel...@stericsson.com writes:
> > From: Vikram ARV
> >
> > Add the the Virtio shared memory driver for STE Modems.
> > caif_virtio is implemented utilizing the virtio framework
> > for data transport and is managed with the
Hi Ido,
> > +void rproc_virtio_get(struct virtio_device *vdev, unsigned offset,
> > + void *buf, unsigned
> len)
> > +{
> > + struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
> > + void *cfg = &rvdev->rsc->vring[rvdev->rsc->num_of_vrings];
> > +
Hi Ido,
> From: Ido Yariv [mailto:i...@wizery.com]
> > +struct resource_table *rproc_elf_get_rsctab_addr(struct rproc *rproc,
> > +const struct firmware *fw)
> > +{
> > + struct elf32_shdr *shdr;
> > +
> > + shdr = find_rsc_shdr(&rproc->dev, (struct
Hi Ido,
> From: Ido Yariv [mailto:i...@wizery.com] Friday, December 21, 2012 3:16 AM
> > Load the firmware once and pave the way for two way
> > communication of virtio configuration and status bits.
> > The virtio ring device address is now stored in the resource
> > table.
> >
> > NOTE: This p
Hi Ido,
> > +static struct elf32_shdr *
> > +find_rsc_shdr(struct device *dev, struct elf32_hdr *ehdr)
> > {
> > - struct elf32_hdr *ehdr;
> > struct elf32_shdr *shdr;
> > + int i;
> > const char *name_table;
> > - struct device *dev = &rproc->dev;
> > struct resource_table *tab
Hi Ido,
> On Fri, Dec 14, 2012 at 05:06:56PM +0100, Sjur Brændeland wrote:
> > Postpone the registration of virtio devices until all
> > vritio ring resource has been allocated.
> > This fixes the following bug: The driver's start callback
> > is called before all vring notify ids are allocated an
> > Add state RPROC_LOADED as firmware loading and startup will be
> > different states.
> >
> > Signed-off-by: Sjur Brændeland
>
> The rproc_state holds the state of the remote processor and it will
> still be offline even when the FW is loaded, so I'm not sure if a new
> state should be added.
Hi Ido,
> > Set the vring addresses in the resource table so that
> > the remote device can read the actual addresses used.
> >
> > Signed-off-by: Sjur Brændeland
>
> Since this new member will only be referenced in the last patch, perhaps
> squash the two patches?
This patch fixes two TODOs in
> This patch should probably be squashed with the next one, since it
> doesn't do much on its own.
OK.
Regards,
Sjur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
Hi Ido,
]
> > > In case the remote processor is added, booted and then rebooted, the
> > > program sections wont be reinitialized. This can be a bit problematic,
> > > since the firmware might assume values are initialized in its data
> > > sections.
> > >
> > > How about the following alternative
Hi Ido,
> > Ugh, thanks I missed this. How about calling rproc_alloc_vring from
> > rproc_parse_vring so that the resource allocation are done before
> > the virtio devices are started?
> I don't think that would solve it - rproc_parse_vring is called from
> rproc_handle_vdev which is called more
Hi Ido,
> From: Ido Yariv [mailto:i...@wizery.com]
> > Postpone the registration of virtio devices until all
> > vritio ring resource has been allocated.
> > This fixes the following bug: The driver's start callback
> > is called before all vring notify ids are allocated and
> > max_notifyid will
Hi Ido and Ohad,
> In case the remote processor is added, booted and then rebooted, the
> program sections wont be reinitialized. This can be a bit problematic,
> since the firmware might assume values are initialized in its data
> sections.
>
> How about the following alternative approach - inst
> Amit Shah [mailto:amit.s...@redhat.com] writes:
> On (Wed) 12 Dec 2012 [10:31:04], Rusty Russell wrote:
> > Amit Shah writes:
> > > On (Tue) 11 Dec 2012 [09:39:41], Rusty Russell wrote:
> > >> Amit Shah writes:
> > >> > On (Fri) 16 Nov 2012 [11:22:09], Rusty Russell wrote:
> > >> >> Amit Shah
> On (Fri) 02 Nov 2012 [09:52:08], Rusty Russell wrote:
> > Amit Shah writes:
> > > On (Tue) 23 Oct 2012 [12:17:49], Rusty Russell wrote:
> > >> sjur.brandel...@stericsson.com writes:
> > >> > From: Sjur Brændeland
> > >
> > >> > @@ -1415,7 +1524,16 @@ static void remove_port_data(struct port
> *
> From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: 9. oktober 2012 16:39
> On Tue, Oct 9, 2012 at 4:26 PM, Dan Carpenter
>
> wrote:
>> If it already compiles fine on x86 then there is no advantage to
>> disabling it.
>
> Not really; that's really a hardware question and not a software one.
>
Hi Ohad,
> On Tue, Oct 2, 2012 at 10:24 AM, Ohad Ben-Cohen
> wrote:
> > On Mon, Oct 1, 2012 at 4:45 AM, Fengguang Wu
> wrote:
> >> Hi Ohad,
> >>
> >> FYI, kernel build failed on
> >>
> >> tree: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
> for-next
> >> head: bec109a430
> > This merge reduces code size by unifying the approach for
> > sending scatter-lists and regular buffers. Any type of
> > write operation (splice, write, put_chars) will now allocate
> > a port_buffer and send_buf() and free_buf() can always be used.
>
> Thanks!
> This looks much nicer and simp
Hi Amit,
> I'm sorry for not being able to look at this earlier.
No worries. I'll try to respin and retest this patch by tomorrow.
If you by any chance could find time to review so could make it in time
for 3.7 it would be great :-)
> A general comment is to base this patchset on linux-next; we'
Hi Rusty,
> > +#if IS_ENABLED(CONFIG_REMOTEPROC)
> > +static inline bool is_rproc_serial(struct virtio_device *vdev)
> > +{
> > + return vdev->id.device == VIRTIO_ID_RPROC_SERIAL;
> > +}
> > +#else
> > +static inline bool is_rproc_serial(struct virtio_device *vdev)
> > +{
> > + return false;
>
Hi Ohad,
> > + /* Provide callbacks to modem device */
> > + mdev->drv_ops = &sproc_drv_ops;
>
> Implicitly providing the modem with drv_ops and drv_data in this
> manner feels racy and somewhat error prone.
>
> E.g., on remove these members are set to NULL, under the assumption
> th
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> sjur.brandel...@stericsson.com wrote:
> > From: Sjur Brændeland
> >
> > Add a simple serial connection driver called
> > VIRTIO_ID_RPROC_SERIAL (0xB) for communicating with a
> > remote processor in an asymmetric multi-processing
> > configurat
platform_device_{un}register, so I I'd personally just drop them and
> call the code directly. This way your code will be a bit more readable
> for others.
OK, will remove these register/unregister functions.
The reason I did include them was to be able to move away from the
platform bus, i
Hi Ohad,
> > One way for the device to figure out the translation between
> > host-physical and device-address is to peek into some CarveOut
> > resource entry and compute this translation. Because a CarveOut
> > resource entry contains both the host-physical-address and the
> > device address for
Hi Fernando,
> > I think you drop the driver module's ref count during recovery, because
> > rproc_shutdown calls module_put(). Maybe you should move driver
> > ref count handling to rproc_add and rproc_type_release, instead of
> > rproc_boot() and rproc_shutdown()?
>
> How could you remove the r
> In net/caif/chnl_net.c::chnl_recv_cb() we call skb_header_pointer()
> which may return NULL, but we do not check for a NULL pointer before
> dereferencing it.
> This patch adds such a NULL check and properly free's allocated memory
> and return an error (-EINVAL) on failure - much better than cra
Hi Ohad,
>>> It seems to me that a char device will solve these issues: we can use
>>> ioctl to control the power, if the user crashes we'll know about it
>>> via the release handler, and if the remote processor crashes we can
>>> let the user know by sending it a notification for it to read via t
Hi Ohad,
I have one question related to address translation between device
address and host-physical address referencing the data-buffer
transported in the virtio-rings.
The address used in the virtio-ring is the host-physical-address,
but the mapping between device-address and host-physical-addre
29 matches
Mail list logo
