On Thu, Oct 15, 2015 at 10:47:09AM -0700, Brian Norris wrote:
> Hmm, I don't know. I wouldn't expect people should really be using
> cmdlineparts as a production solution, but I'd consider it more of a
> debugging/development option -- if I want to override the DT (which is
> sometimes a bit harder
On Thu, Oct 15, 2015 at 09:22:10AM -0700, Brian Norris wrote:
> Are you trying to use this binding, or is this just purely a mechanical
> documentation issue? I ask, because it seems that binding never really
> got reviewed at all, and others have recently tried to extend
> support
I wrote it bef
On Thu, Jul 23, 2015 at 02:55:52PM -0700, Moritz Fischer wrote:
> Hi Alan,
>
> I saw that your socfpga driver doesn't support the partial reconfig
> use case (not a big deal).
> What I currently do for Zynq is if I'm doing a non-partial reconfig is
> that I disable input
> level shifters and asser
On Wed, Jul 22, 2015 at 03:32:32PM -0500, atull wrote:
> I looked some more; I don't see a simple way of deferring probing until
> after the filesystem is loaded (so that the image file would be
> available), late_initcall is still not late enough.
That seems weird, are you saying you can't use
On Fri, Jul 17, 2015 at 09:49:13PM +0200, Steffen Trumtrar wrote:
> What you are describing here is a virtual bus, that is not existing on
> at least the Socfpga, right?
I wouldn't get too hung up on bus or not bus, the HW these days
doesn't even use busses.
For AXI systems, which is all the ARM
On Fri, Jul 17, 2015 at 10:51:10AM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> This patchset adds two chunks plus documentation:
> * fpga manager core: exports ABI functions that write an image to a FPGA
> * DT Overlay support: simple-fpga-bus to handle FPGA from a DT overla
On Thu, Jul 09, 2015 at 02:49:08PM +0200, Jens Wiklander wrote:
> > Generally in a scheme like this we'd see open and release get/put the
> > underlying module handle to prevent driver removal while the char dev
> > is open. Otherwise module removal will hang here.
>
> I'm perhaps misunderstanding
On Wed, Jul 08, 2015 at 03:33:25PM -0700, Greg Kroah-Hartman wrote:
> > The basic issue is that cdev_del doesn't seem to be synchronizing.
> >
> > The use after free race is then something like:
> >
> >struct tpm_chip {
> > struct device dev;
> > struct cdev cdev;
>
> Oops, right the
On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
> > > + cdev_init(&teedev->cdev, &tee_fops);
> > > + teedev->cdev.owner = teedesc->owner;
> >
> > This also needs to set teedev->cdev.kobj.parent.
> > I'm guessing:
> >
> > teedev->cdev.kobj.parent = &teedev->dev.kob
On Wed, Jul 08, 2015 at 12:16:30PM +0200, Jens Wiklander wrote:
> +static void tee_device_complete_unused(struct kref *kref)
> +{
> + struct tee_device *teedev;
> +
> + teedev = container_of(kref, struct tee_device, users);
> + /* When the mutex is released, no other tee_device_get() w
On Mon, Apr 20, 2015 at 08:20:44AM +0200, Jens Wiklander wrote:
> I'm not sure I understand what you mean. This function is a building
> block for the TEE driver to supply whatever interface is needed for user
> space. For a Global Platform like TEE it will typically have support for
> TEEC_OpenSe
On Mon, Apr 20, 2015 at 03:02:03PM +0200, Jens Wiklander wrote:
> > It appeared to me this driver was copying TPM's old architecture,
> > which is very much known to be broken.
>
> The struct tee_device holds a shared memory pool from which shared
> memory objects are allocated. These shared memor
On Mon, Apr 20, 2015 at 04:54:32PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Apr 19, 2015 at 11:08:00PM -0600, Jason Gunthorpe wrote:
> > I still suspect the expected way to write a new mid layer is to create
> > your own struct device and not rely on misc_device,
>
> Yes,
On Sat, Apr 18, 2015 at 10:57:55PM +0100, Russell King - ARM Linux wrote:
> > But then we trundle down to:
> >
> > + ctx->teedev->desc->ops->get_version(ctx, &vers.spec_version,
> > + vers.uuid);
> >
> > If we kref teedev so it is valid then calling a driver call back after
> > (or during) it'
On Sat, Apr 18, 2015 at 10:01:47AM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote:
> > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> > > + teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
&
On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote:
> + teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL);
[..]
> + rc = misc_register(&teedev->miscdev);
[..]
> +void tee_unregister(struct tee_device *teedev)
> +{
[..]
> + misc_deregister(&teedev->miscdev);
> +}
[..]
>
On Sun, Feb 15, 2015 at 11:40:06PM +0100, Pavel Machek wrote:
> > So keeping that much memory pinned in the kernel when I can prove it
> > is uncessary for my system (either because there is no suspend/resume
> > possibility, or because I know the CPU can always access the
> > filesytem) is very u
On Wed, Jan 28, 2015 at 10:49:39PM +0100, peterhu...@gmx.de wrote:
> >> I will go for a define making the code more readable together with a
> >> comment.
> >
> >You can probably just make these static arrays inside your priv
> >structure and drop these independent allocations:
>
> Hmm, doesn' t
On Wed, Jan 28, 2015 at 08:13:33PM +0100, RICARD Christophe wrote:
> Hi Peter,
>
> A TPM command can be up to 2048 byte, A TPM response can be up to 1024 byte.
> Between command and response, there are latency byte (up to 15
> usually on st33zp24 2 are enough).
>
> Overall when sending a command
;>
> >>> On Jan 15, 2015, at 22:45 , One Thousand Gnomes
> >>> wrote:
> >>>
> >>> On Thu, 15 Jan 2015 11:47:26 -0700
> >>> Jason Gunthorpe wrote:
> >>>> It is a novel idea, my concern would be that embedding t
On Thu, Jan 15, 2015 at 08:45:02PM +, One Thousand Gnomes wrote:
> > - Hand over to a DT overlay (how does this work?) Lock transfers
> > from FD to kernel
>
> That bit isn't stateful so I would actually have expected something in
> the kernel ABI along the lines of
>
>request
On Thu, Jan 15, 2015 at 10:34:39AM -0600, atull wrote:
> This is great! The way I had it working was using Pantelis' devicetree
> configfs interface.
I figured you were very close to this already in your overlay work..
> The DT fragment described the FPGA logic and included a filename
> for fi
On Wed, Jan 14, 2015 at 04:06:17PM +, One Thousand Gnomes wrote:
> and I think you effectively have the user usage covered here for such
> things. It much like GPIO pins - we can describe them but we can also
> declare they are not visible to the user.
A missing element in mainline is a kind
On Tue, Jan 13, 2015 at 03:37:14PM -0600, atull wrote:
> > I do agree with this, and I think this is where this patch set goes so
> > wrong.
> >
> > Just exposing all sorts of controls to userspace and having a way for
> > the kernel to load/unload a bitstream compleletely misses the point that
>
On Tue, Jan 13, 2015 at 04:28:47PM +, One Thousand Gnomes wrote:
> There is a lot of code overlap in things like loading the bitstreams,
> there is also some overlap because you want to be able to assign FPGA
> resources. For example if you have four FPGAs and you want to use one for
> OS stuf
On Mon, Jan 12, 2015 at 09:01:34PM +, One Thousand Gnomes wrote:
> There are plenty of people today who treat the FPGA as an entirely
> dynamic resource. It's not like flashing a controller, its near
> immediate.
But this is a completely different use case. Remember, there are
*megabytes* of i
On Sat, Jan 10, 2015 at 12:20:29PM +0100, Christophe Ricard wrote:
For reference:
> -static int tpm_stm_i2c_remove(struct i2c_client *client)
> -{
> - struct tpm_chip *chip =
> - (struct tpm_chip *) i2c_get_clientdata(client);
> -
> - if (chip)
> -tpm_chi
ch 8
Patch 4 and 6 do not seem to be part of this series and seem to be
bug fixes, the should be seperated so Peter can fast track them
into the kernel.
So excluding patch 8:
Reviewed-By: Jason Gunthorpe
Jason
--
To unsubscribe from this list: send the line "unsubscribe devicet
On Sun, Jan 11, 2015 at 10:29:00AM -0600, atull wrote:
> the FPGA image. If someone wants there to be only one FPGA image on
> the FGPA forever, they will probably not be using this framework; their
> FPGA will probably be loaded before Linux boots up.
Nonsense, loading the FPGA through Linux is
On Thu, Oct 23, 2014 at 12:27:31PM +0100, Lorenzo Pieralisi wrote:
> I think that by removing that, we could switch to CONFIG_PCI_DOMAINS_GENERIC
> on ARM32. I will remove the dependency in drivers/pci/host/pci-mvebu.c
> introduced by commit 2613ba48. pci_sys_data.domain is always 0 in that
> driv
On Tue, Oct 14, 2014 at 10:44:25PM +0200, Christophe RICARD wrote:
> > > + r =
> > > wait_event_interruptible_timeout(chip->vendor.read_queue,
> > > + check_locality(chip) >= 0,
> > > + timeout);
> >
> > Can it use wait_for_s
Fix potential bug in tpm_stm_i2c_send
> tpm/tpm_i2c_stm_st33: Change License header to have up to date address
> information
> tpm/tpm_i2c_stm_st33: Increment driver version to 1.2.1.
You can add my
Reviewed-By: Jason Gunthorpe
On the above in the series
Thanks,
Jason
--
To unsubscribe
On Mon, Oct 13, 2014 at 10:23:33PM +0200, Christophe Ricard wrote:
> The tpm layer already provides a function to wait for a TIS event
> wait_for_tpm_stat. Exactly like wait_for_serirq_timeout, it can work in
> polling or interrupt mode.
> Instead of using a completion struct, we rely on the waitqu
On Mon, Oct 13, 2014 at 10:23:30PM +0200, Christophe Ricard wrote:
> Add tpm_stm_st33_i2c dts structure keeping backward compatibility
> with static platform_data support as well.
> In the mean time the code is made much simpler by:
> - Moving all gpio_request to devm_gpio_request_one primitive
>
On Thu, Oct 09, 2014 at 07:35:07PM +0200, Christophe Henri RICARD wrote:
> Hi Jason,
>
> > If your chip is sane like other TPMs the IRQ pin will *only* be
> > asserted while there is data pending in the out command FIFO,
> > reading the FIFO *should naturally clear the IRQ *and the acking
> > proc
On Wed, Oct 08, 2014 at 11:14:40PM +0200, Christophe Henri RICARD wrote:
> For your information, the lpcpd pin is named like this as per
> PCClientTPMSpecification is also known as TPMSTB on this product.
> The TPMSTB pin can be used in order to support D1 and D2 power
> management state. I am ac
On Wed, Oct 08, 2014 at 10:41:36PM +0200, Christophe Henri RICARD wrote:
> Hi Jason,
>
> I have currently seen both. I agree on the principles as it is
> simplifying the code a little bit. I including this clean up in
> this patch Add devicetree structure for a future v2 submission
I was just lo
On Wed, Oct 08, 2014 at 10:26:57PM +0200, Christophe Henri RICARD wrote:
> Hi Jason,
>
> Patch 10/16 includes the following lines:
> + if (r == -ERESTARTSYS && freezing(current)) {
> + clear_thread_flag(TIF_SIGPENDING);
> + goto again;
> +
On Wed, Oct 08, 2014 at 07:36:04AM +0200, Christophe RICARD wrote:
> I believe this is completely 2 different things. The delay before the
> release locality is to make sure that the isr will be service before
> release_locality to guarantee
> that any pending interrupt are cleared while the local
On Wed, Oct 08, 2014 at 07:47:58AM +0200, Christophe RICARD wrote:
> >>+ if (interrupts) {
> >>+ r = devm_gpio_request_one(&client->dev, pdata->io_serirq,
> >>+ GPIOF_IN, "TPM IO_SERIRQ");
> >Similarly, I wonder if pdata->io_serirq is just duplication o
On Wed, Oct 08, 2014 at 09:38:39AM +0200, Christophe Ricard wrote:
>I would just add an additional comment to my previous message.
>After reviewing Documentation/stable_kernel_rules.txt, it looks like it
>is *not* necessary to send this patch marked as stable because of the
>followi
On Wed, Oct 08, 2014 at 07:38:30AM +0200, Christophe RICARD wrote:
> Hi Jason,
>
> The freezer header is here for the freezing(current) function call
> in get_burstcount().
But freezing(current) does not occur in patch 10/16.
Is this include in the right patch in the series?
Jason
--
To unsubs
On Tue, Oct 07, 2014 at 10:03:00PM +0200, Christophe Ricard wrote:
> +_irq_probe:
> + /* IRQ */
> + r = irq_of_parse_and_map(pp, 0);
> + if (r < 0) {
> + pr_err("Unable to get irq, error: %d\n", r);
> + interrupts = 0;
> + goto _end;
> + }
> +
On Tue, Oct 07, 2014 at 10:02:53PM +0200, Christophe Ricard wrote:
> Hi Peter,
>
> The following patchset brings:
> - Some few code clean up from code style up to structure
> - Device tree support keeping static platform data configuration support.
> - Fix irq support.
> - Update the GPLv2 license
On Tue, Oct 07, 2014 at 10:03:03PM +0200, Christophe Ricard wrote:
> +++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
I'm surprised to see that include here..
Jason
--
To unsubscribe from this list: send the line "unsubscribe devic
On Tue, Oct 07, 2014 at 10:03:04PM +0200, Christophe Ricard wrote:
> Remove useless i2c read on TPM_INT_ENABLE and TPM_INT_STATUS
>
> Signed-off-by: Christophe Ricard
> drivers/char/tpm/tpm_i2c_stm_st33.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_i2c_
he first patch in your series so it applies
cleanly to older kernels.
Reviewed-By: Jason Gunthorpe
> Signed-off-by: Christophe Ricard
> drivers/char/tpm/tpm_i2c_stm_st33.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/tpm/tpm_i2c_
On Tue, Oct 07, 2014 at 10:03:08PM +0200, Christophe Ricard wrote:
> In order to manage irq, locality must be active. As Status Ready
> interrupt is activated, when going back into ready state with the
> cancel function, we need to add a little delay to make sure the irq
> is going to be serviced b
On Tue, Oct 07, 2014 at 10:03:06PM +0200, Christophe Ricard wrote:
> Adding tpm_lock mutex in order to guarantee that a i2c_read_data or a
> i2c_write_data will not get interrupted by a threaded interrupt.
Can you elaborate on this?
Any call from the TPM core itself through 'ops' is locked alread
On Tue, Oct 07, 2014 at 10:02:54PM +0200, Christophe Ricard wrote:
> STMicroelectronics i2c tpm is the only one to have a different tristate
> label.
>
> Rename it "TPM Interface Specification 1.2 Interface (I2C -
> STMicroelectronics)"
Looks fine, but why move the stanza? Are you sorting on the
On Mon, Sep 22, 2014 at 04:09:03PM -0600, Bjorn Helgaas wrote:
> On Mon, Sep 22, 2014 at 3:33 PM, Tanmay Inamdar wrote:
>
> >>> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
> >>> +{
> >>> + int i;
> >>> +
> >>> + /* Hide the PCI host BARs from the kernel as their content does
On Tue, Sep 09, 2014 at 09:44:56PM -0500, Rob Herring wrote:
> On Tue, Sep 9, 2014 at 10:41 AM, Jason Gunthorpe
> wrote:
> > On Tue, Sep 09, 2014 at 08:26:19AM -0600, Bjorn Helgaas wrote:
> >
> >> So as long as the DT tells you the ECAM information for each host
On Tue, Sep 09, 2014 at 08:26:19AM -0600, Bjorn Helgaas wrote:
> So as long as the DT tells you the ECAM information for each host
> bridge, that should be sufficient. The domain number is then just a
> Linux convenience and is not tied to the platform as it is on ia64.
I think this is right for
On Mon, Sep 08, 2014 at 04:59:31PM +0100, Liviu Dudau wrote:
> > I don't really understand how domains are used so it's hard to provide
> > a recommendation here. Do domains even belong in the DT?
>
> ACPI calls them segments and the way Bjorn explained it to me at some moment
> was
> that it wa
On Fri, Aug 29, 2014 at 11:23:57AM -0700, Florian Fainelli wrote:
> On 08/29/2014 10:31 AM, Jason Gunthorpe wrote:
> > On Fri, Aug 29, 2014 at 08:35:36AM -0700, Sören Brinkmann wrote:
> >
> >> The compatible string is listed as optional property for PHYs. So, not
> &g
On Fri, Aug 29, 2014 at 08:35:36AM -0700, Sören Brinkmann wrote:
> The compatible string is listed as optional property for PHYs. So, not
> having one is an option, I guess. But, I'd also prefer to at least keep
> the -c22 one, since I saw problems when I tried using -c45 (the Zed phy
> should sup
On Fri, Aug 22, 2014 at 01:47:09PM -0700, Florian Fainelli wrote:
> > - the ID based strings seem to be not needed since, IIUC, the core
> >reads the ID from the PHY and uses it, so I just left it out not
> >trying to figure out how to obtain the correct ID
>
> It is not needed, but it i
On Fri, Aug 22, 2014 at 09:31:20AM -0700, Sören Brinkmann wrote:
> > > - the marvell compatible strings are used in our vendor tree. They
> > >aren't used anywhere but in our vendor tree. I though keeping them is
> > >nice since it identifies the PHY fully. And in case that level of
> > >
On Thu, Aug 21, 2014 at 08:49:19AM -0700, Sören Brinkmann wrote:
> So my thinkings:
> - the compatible string with the -c22 is used and documented in the phy
>bindings, it should be there.
Yes
> - the ID based strings seem to be not needed since, IIUC, the core
>reads the ID from the P
> >> Hm, are you sure about that? I thought only PCI devices should have
> >> it...
>
> >Yes, pretty sure it's needed in both the host controller and the
> >devices.
>
> I don't understand the case of the PCI devices, honestly.
> Shouldn't the "device_type" prop reflect the device's fun
On Fri, May 30, 2014 at 02:41:17AM +0100, Liviu Dudau wrote:
> Agree, I'm only concerned that if this ECAM config space gets added to
> the list of pci_host_bridge windows it will be indistinguishable from
> IORESOURCE_MEM resources and pci_create_root_bus() will add it to the
> bus and allow devi
On Thu, May 29, 2014 at 11:03:36AM -0500, Kumar Gala wrote:
> Just because the kernel doesn’t handle this is NO reason to change
> the way the DT works.
The OF specs do not specify how to process a config type ranges entry,
and we all mutually agreed that the only sane interpretation for such
a t
oper resource
associated with it, or the PCI core won't create sub resources.
commit 2613ba480fb7b40c67eea36d03c9946977828623
Author: Jason Gunthorpe
Date: Wed Feb 12 15:57:08 2014 -0700
PCI: mvebu: Call request_resource() on the apertures
It is typical for host drivers to request a resource for the
On Fri, May 16, 2014 at 10:53:33AM +0100, Will Deacon wrote:
> > Correct. Assume a PCI device uses PIO and DMA. It sends a DMA to main memory
> > and lets the CPU know about the data using a level (IntA as opposed to MSI)
> > interrupt. The CPU performs an outl() operation to an I/O port to let th
On Tue, May 20, 2014 at 09:30:33PM +0200, Boris BREZILLON wrote:
> AFAICT nothing, but the same goes for the ECC requirements, and we've
> recently added DT bindings to define these requirements.
> I'm not telling we should drop these ECC requirements bindings (actually
> I'm using them :-)), but
On Fri, May 16, 2014 at 10:57:36AM +0100, Will Deacon wrote:
> > AFAIK, to duplicate x86 semantics an outl/inl must spin the CPU until
> > it completes at the target, and the CPU must not pipeline outl/inl
> > operations: outl(); outl(); produces 1 IOWr TLP, waits for
> > completion, then produces
On Thu, May 15, 2014 at 04:34:30PM +0100, Will Deacon wrote:
> > How can a write be non-posted on the PCI bus if it's posted on AXI?
>
> From the point-of-view of the CPU it would be posted, but the PCI bus would
> see an unposted write (so I imagine there would be write buffering at the
> host c
On Fri, May 09, 2014 at 03:16:33PM +0100, Dave Martin wrote:
> On Fri, May 02, 2014 at 12:17:50PM -0600, Jason Gunthorpe wrote:
> > I wonder if this might be a better naming scheme, I actually don't
> > really like 'slave' for this, it really only applies well t
On Thu, May 08, 2014 at 06:37:49PM +0200, Sylwester Nawrocki wrote:
> This patch adds a helper function to unregister devices which
> were created by an of_platform_populate() call. The pattern
> used here can already be found in multiple drivers. This helper
> can now be used instead of repeating
On Tue, May 06, 2014 at 07:03:51PM +0530, Kishon Vijay Abraham I wrote:
> +Example:
> +pcie@5100 {
> + compatible = "ti,dra7xx-pcie";
> + reg = <0x51002000 0x14c>, <0x5100 0x2000>;
> + reg-names = "ti_conf", "rc_dbics";
> + interrupts = <0 232 0x4>, <0 233 0x4>;
> + #add
On Fri, May 02, 2014 at 06:31:20PM +0100, Dave Martin wrote:
> Note that there is no cycle through the "reg" property on iommu:
> "reg" indicates a sink for transactions; "slaves" indicates a
> source of transactions, and "ranges" indicates a propagator of
> transactions.
I wonder if this might b
On Thu, May 01, 2014 at 10:56:06PM +0200, Boris BREZILLON wrote:
> > However, with a synchronous scrambler the security concern boils down
> > to how robust and unpredictable is the PRBS.
>
> I'm not sure security is the main concern here.
> AFAICT, NAND scramblers (note that I stopped using the
On Thu, May 01, 2014 at 07:31:13PM +0200, Boris BREZILLON wrote:
> I totally agree with you, this is not a randomizer but rather a scrambler.
> The reason I chose the "randomizer" word is that all the documents I
> read are talking about randomizers.
> But, other than I don't have any concern abou
On Thu, May 01, 2014 at 03:09:49AM +0200, Boris BREZILLON wrote:
> Hello,
>
> This series is a proposal to add support for randomizers (either software
> or hardware) to NAND flash controller drivers.
FWIW, I think the term for reversibly combining a PRBS with data is
'scrambling', it is often us
On Wed, Apr 30, 2014 at 09:39:41PM +0200, Sebastian Hesselbarth wrote:
> On 04/30/2014 06:42 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 30, 2014 at 02:56:34PM +0200, Sebastian Hesselbarth wrote:
> >> All SoCs have the same pinctrl setting for NAND, UART0/1, SPI, TWSI0,
> &g
On Wed, Apr 30, 2014 at 02:56:34PM +0200, Sebastian Hesselbarth wrote:
> All SoCs have the same pinctrl setting for NAND, UART0/1, SPI, TWSI0,
> and GBE1. Move it to the common pinctrl node that we now have.
There are two possible choices for UART0, UART1, and SPI on kirkwood..
For instance I use
On Thu, Apr 17, 2014 at 01:20:42AM +0100, Liviu Dudau wrote:
> > No spec says you can put config space into the ranges at all, nobody
> > should be doing that today, obviously some cases were missed during
> > review..
>
> ePAPR documents allows that when ss == 00.
Which do you mean? The 'PCI Bu
ange flags and
> resource type as is (filtered through the IORESOURCE_TYPE_BITS) will lead
> to a resource type of value zero, which is not recognised by any resource
> handling API so bridge configuration and bus scanning will barf.
>
> I'm looking for suggestions here, as Jason Gunth
On Fri, Apr 11, 2014 at 11:10:59PM +0530, Srikanth Thokala wrote:
> I see this error too on my setup (Xilinx PCIe Root Complex Driver),
> https://lkml.org/lkml/2014/3/3/183
> After digging into it, I see I need to override the API
> pcibios_get_phb_of_node()
No, as I pointed out before, the DT n
On Tue, Apr 08, 2014 at 09:03:27AM +0200, Michal Simek wrote:
> > If in doubt follow common mainline practice. Although using includes
> > for DT is not necessarily common practice, readability of DTs is
> > really important IMHO.
>
> Let me give you one example. When you add xilinx intc controll
On Mon, Apr 07, 2014 at 02:24:07PM +0200, Michal Simek wrote:
> Device-tree BSP and in 2014.01 there will be new BSP which just
> generate them directly from the Vivado tools which just target your
> reference design. You can connect your custom IP (or Xilinx or 3rd
> party) directly to the GIC w
On Wed, Mar 26, 2014 at 09:28:42AM -0500, Rob Herring wrote:
> Where is the right place for config space? This binding has it here
> and others have it in ranges.
I think all the drivers in drivers/pci/host use 'reg', this was
discussed in the dt-bindings list and AFAIK no new drivers have used
On Wed, Mar 12, 2014 at 06:54:56PM -0300, Ezequiel Garcia wrote:
> On Mar 12, Jason Gunthorpe wrote:
> > On Wed, Mar 12, 2014 at 06:11:47PM -0300, Ezequiel Garcia wrote:
> >
> > > I've pushed a branch so people can test this easily, e.g. ensuring
> > > no reg
On Tue, Mar 18, 2014 at 01:02:55PM -0700, Tim Harvey wrote:
> > Is this whole bridge/switch hierarchy binding documented somewhere
> > or is this just something that work for you?
>
> I'm not sure where its 'best' documented, but it is the way the
> kernel works.
It is documented in the 'PCI Bus
On Wed, Mar 12, 2014 at 06:11:47PM -0300, Ezequiel Garcia wrote:
> I've pushed a branch so people can test this easily, e.g. ensuring
> no regressions on Dove, Kirkwood and A370/XP:
>
> https://github.com/MISL-EBU-System-SW/mainline-public/tree/wdt_a385_a375_v3
This branch worked for me, the wat
On Wed, Mar 12, 2014 at 05:46:53PM +0100, Boris BREZILLON wrote:
> >>I see at least 3 of those timings that could be useful (for the moment) :
> >>- tR: this one should be used to fill the chip_delay field
> >>- tPROG and tBERS: could be used within nand_wait to choose the timeo
> >> value appro
On Thu, Mar 06, 2014 at 09:13:46PM -0300, Ezequiel Garcia wrote:
> > On the driver side, we need to implement per-SoC stop() and enabled()
> > functions. Such somewhat complex infrastructure is needed to ensure the
> > driver
> > performs proper reset of the watchdog timer, by masking and disabli
On Mon, Mar 10, 2014 at 02:44:04PM +0100, Boris BREZILLON wrote:
> Some timings are missing here (see Table 55 in the ONFI spec):
Right..
The 'mode' covers only the raw electrical parameters needed to
exchange commands, other timings cover the commands
themselves. Notably the timing mode does no
On Mon, Mar 10, 2014 at 12:17:31PM +0100, Boris BREZILLON wrote:
> Hello Jason,
>
> Le 29/01/2014 20:10, Jason Gunthorpe a écrit :
> >On Wed, Jan 29, 2014 at 03:46:20PM -0300, Ezequiel Garcia wrote:
> >
> >>After CE# has been pulled high and then transitioned low ag
On Wed, Mar 05, 2014 at 02:25:51PM +0100, Lucas Stach wrote:
> - return pp->irq;
> + irq = of_irq_parse_and_map_pci(dev, slot, pin);
> + if (!irq)
> + irq = pp->irq;
In light of the two bugs that Tim found, it might be wise to throw a
'dev_warn(FW_BUG "Missing DT interrupt
On Mon, Mar 03, 2014 at 03:40:43PM -0800, Tim Harvey wrote:
> of_irq_parse_and_map_pci(). The GIC function that translates the
> interrupt per domain is given irq_data: 0x123 0x04 0x00
This has been shifted by 1 byte..
> IRQ 123, which should get 32 added to it for irq155). Instead, the
> imp
On Tue, Mar 04, 2014 at 12:21:55AM +0530, Srikanth Thokala wrote:
> >> + pci_express: axi-pcie@5000 {
> >> + #address-cells = <3>;
> >> + #size-cells = <2>;
> >> + compatible = "xlnx,axi-pcie-host-1.00.a";
> >> + reg = < 0x5000 0x1000
On Mon, Mar 03, 2014 at 09:49:52AM -0800, Tim Harvey wrote:
> I'm not clear why irq 20 is getting returned for all the slots with
> (slot%4)=0 and func=0. If I start debugging of_irq_parse_pci() I see
> that it walks up the tree until it gets to the pcie host controller
> then calls of_irq_parse_
On Mon, Mar 03, 2014 at 07:10:36PM +0530, Srikanth Thokala wrote:
> +Required properties:
> +- #address-cells: Address representation for root ports, set to <3>
> +- #size-cells: Size representation for root ports, set to <2>
> +- compatible: Should contain "xlnx,axi-pcie-host-1.00.a"
> +- reg: Sh
On Fri, Feb 28, 2014 at 04:53:33PM -0800, Tim Harvey wrote:
> In testing this on IMX6 I'm finding that 'of_irq_parse_and_map_pci()'
> always returns -EINVAL because it can't find a dt node for the host
> bridge:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/of/of_p
On Thu, Feb 27, 2014 at 08:48:08PM +0100, Arnd Bergmann wrote:
> > It also looks correct for architectures that use the CPU MMIO address
> > as the IO address directly (where IO_SPACE_LIMIT would be 4G)
>
> Are you aware of any that still do? I thought we had stopped doing
> that.
I thought ia64
On Thu, Feb 27, 2014 at 07:12:59PM +, Liviu Dudau wrote:
> The outstanding issue is how to fix pci_address_to_pio() as it will not
> for for range->cpu_addr > IO_SPACE_LIMIT (16MB in my case).
The default actually looks fine to me, it is the correct behavior for
systems that actually have a de
On Thu, Feb 27, 2014 at 01:06:39PM +, Liviu Dudau wrote:
> + if (res->flags & IORESOURCE_IO) {
> + unsigned long port;
> + port = pci_address_to_pio(range->pci_addr);
This looks very suspicious, pci_addr is not unique across all domains,
so there is no way to conver
On Mon, Feb 17, 2014 at 03:54:19PM +, Grant Likely wrote:
> I applied a patch that did exactly that (109b623629), and then reverted
> it (b920ecc82) shortly thereafter because add_device_randomness() is
> a rather slow function and FDTs can get large. I'd like to see someone
> do a reasonable
On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> The bootloader would then load this file into ram, and pass the
> address/size to the kernel either via dt, or commandline. kaslr (run in
> the decompressor) would consume some of this randomness, and then
> random.c would consume th
1 - 100 of 158 matches
Mail list logo
